<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title> MySQL Glossary</title>
<link rel="stylesheet" href="mvl.css" type="text/css" />
<meta name="generator" content="DocBook XSL Stylesheets + chunker.py v1.9.2" />
<link rel="start" href="index.html" title="{book-title}" />
<link rel="up" href="" title="" />
<link rel="prev" href="dynindex-isolevel.html" title=" Transaction Isolation Level Index" />
<link rel="next" href="" title="" />
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center"> MySQL Glossary</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="dynindex-isolevel.html">Prev</a> </td>
<th width="60%" align="center"></th>
<td width="20%" align="right"> </td>
</tr>
</table>
<hr>
</div>
<div class="glossary">

<div class="titlepage">
<div>
<div>
<h1 class="title"><a name="glossary"></a>MySQL Glossary</h1>

</div>

</div>

</div>
<p>
    These terms are commonly used in information about the MySQL
    database server. This glossary originated as a reference for
    terminology about the InnoDB storage engine, and the majority of
    definitions are InnoDB-related.
</p>
<div class="glossdiv">
<h3 class="title">A</h3>
<dl><dt><a name="glos_arm_file"></a><span class="glossterm">.ARM file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397280304"></a>
        Metadata for <code class="literal">ARCHIVE</code> tables. Contrast with
        <span class="bold"><strong>.ARZ file</strong></span>. Files with this
        extension are always included in backups produced by the
        <code class="literal">mysqlbackup</code> command of the
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_arz_file">.ARZ file</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_mysqlbackup_command">mysqlbackup command</a>.</p></dd><dt><a name="glos_arz_file"></a><span class="glossterm">.ARZ file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397273008"></a>
        Data for ARCHIVE tables. Contrast with
        <span class="bold"><strong>.ARM file</strong></span>. Files with this
        extension are always included in backups produced by the
        <code class="literal">mysqlbackup</code> command of the
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_arm_file">.ARM file</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_mysqlbackup_command">mysqlbackup command</a>.</p></dd><dt><a name="glos_acid"></a><span class="glossterm">ACID</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397346576"></a>
        An acronym standing for atomicity, consistency, isolation, and
        durability. These properties are all desirable in a database
        system, and are all closely tied to the notion of a
        <span class="bold"><strong>transaction</strong></span>. The transactional
        features of <code class="literal">InnoDB</code> adhere to the ACID
        principles.
      </p><p>
        Transactions are <span class="bold"><strong>atomic</strong></span> units
        of work that can be <span class="bold"><strong>committed</strong></span>
        or <span class="bold"><strong>rolled back</strong></span>. When a
        transaction makes multiple changes to the database, either all
        the changes succeed when the transaction is committed, or all
        the changes are undone when the transaction is rolled back.
      </p><p>
        The database remains in a consistent state at all times —
        after each commit or rollback, and while transactions are in
        progress. If related data is being updated across multiple
        tables, queries see either all old values or all new values, not
        a mix of old and new values.
      </p><p>
        Transactions are protected (isolated) from each other while they
        are in progress; they cannot interfere with each other or see
        each other's uncommitted data. This isolation is achieved
        through the <span class="bold"><strong>locking</strong></span> mechanism.
        Experienced users can adjust the <span class="bold"><strong>isolation
        level</strong></span>, trading off less protection in favor of
        increased performance and
        <span class="bold"><strong>concurrency</strong></span>, when they can be
        sure that the transactions really do not interfere with each
        other.
      </p><p>
        The results of transactions are durable: once a commit operation
        succeeds, the changes made by that transaction are safe from
        power failures, system crashes, race conditions, or other
        potential dangers that many non-database applications are
        vulnerable to. Durability typically involves writing to disk
        storage, with a certain amount of redundancy to protect against
        power failures or software crashes during write operations. (In
        <code class="literal">InnoDB</code>, the <span class="bold"><strong>doublewrite
        buffer</strong></span> assists with durability.)
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_atomic">atomic</a>, <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_doublewrite_buffer">doublewrite buffer</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_adaptive_flushing"></a><span class="glossterm">adaptive flushing</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397329392"></a>
        An algorithm for <span class="bold"><strong>InnoDB</strong></span> tables
        that smooths out the I/O overhead introduced by
        <span class="bold"><strong>checkpoints</strong></span>. Instead of
        <span class="bold"><strong>flushing</strong></span> all modified
        <span class="bold"><strong>pages</strong></span> from the
        <span class="bold"><strong>buffer pool</strong></span> to the
        <span class="bold"><strong>data files</strong></span> at once, MySQL
        periodically flushes small sets of modified pages. The adaptive
        flushing algorithm extends this process by estimating the
        optimal rate to perform these periodic flushes, based on the
        rate of flushing and how fast
        <span class="bold"><strong>redo</strong></span> information is generated.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_checkpoint">checkpoint</a>, <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>.</p></dd><dt><a name="glos_adaptive_hash_index"></a><span class="glossterm">adaptive hash index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397318208"></a>
        An optimization for <code class="literal">InnoDB</code> tables that can
        speed up lookups using <code class="literal">=</code> and
        <code class="literal">IN</code> operators, by constructing a
        <span class="bold"><strong>hash index</strong></span> in memory. MySQL
        monitors index searches for <code class="literal">InnoDB</code> tables,
        and if queries could benefit from a hash index, it builds one
        automatically for index <span class="bold"><strong>pages</strong></span>
        that are frequently accessed. In a sense, the adaptive hash
        index configures MySQL at runtime to take advantage of ample
        main memory, coming closer to the architecture of main-memory
        databases. This feature is controlled by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_adaptive_hash_index"><code class="literal">innodb_adaptive_hash_index</code></a>
        configuration option. Because this feature benefits some
        workloads and not others, and the memory used for the hash index
        is reserved in the <span class="bold"><strong>buffer pool</strong></span>,
        typically you should benchmark with this feature both enabled
        and disabled.
      </p><p>
        The hash index is always built based on an existing
        <span class="bold"><strong>B-tree</strong></span> index on the table.
        MySQL can build a hash index on a prefix of any length of the
        key defined for the B-tree, depending on the pattern of searches
        against the index. A hash index can be partial; the whole B-tree
        index does not need to be cached in the buffer pool.
      </p><p>
        In MySQL 5.6 and higher, another way to take advantage of fast
        single-value lookups with <code class="literal">InnoDB</code> tables is to
        use the <code class="literal">InnoDB</code>
        <span class="bold"><strong>memcached</strong></span> plugin. See
        <a class="xref" href="innodb-storage-engine.html#innodb-memcached" title="15.19 InnoDB memcached Plugin">Section 15.19, “InnoDB memcached Plugin”</a> for details.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_b_tree">B-tree</a>, <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_hash_index">hash index</a>, <a class="glossseealso" href="glossary.html#glos_memcached">memcached</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_secondary_index">secondary index</a>.</p></dd><dt><a name="glos_ahi"></a><span class="glossterm">AHI</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397301168"></a>
        Acronym for <span class="bold"><strong>adaptive hash
        index</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_adaptive_hash_index">adaptive hash index</a>.</p></dd><dt><a name="glos_aio"></a><span class="glossterm">AIO</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397297776"></a>
        Acronym for <span class="bold"><strong>asynchronous I/O</strong></span>.
        You might see this acronym in <code class="literal">InnoDB</code> messages
        or keywords.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_asynchronous_io">asynchronous I/O</a>.</p></dd><dt><a name="glos_application_programming_interface"></a><span class="glossterm">application programming interface (API)</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397293632"></a>
        A set of functions or procedures. An API provides a stable set
        of names and types for functions, procedures, parameters, and
        return values.
      </p></dd><dt><a name="glos_apply"></a><span class="glossterm">apply</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397291424"></a>
        When a backup produced by the <span class="bold"><strong>MySQL
        Enterprise Backup</strong></span> product does not include the most
        recent changes that occurred while the backup was underway, the
        process of updating the backup files to include those changes is
        known as the <span class="bold"><strong>apply</strong></span> step. It is
        specified by the <code class="literal">apply-log</code> option of the
        <code class="literal">mysqlbackup</code> command.
      </p><p>
        Before the changes are applied, we refer to the files as a
        <span class="bold"><strong>raw backup</strong></span>. After the changes
        are applied, we refer to the files as a
        <span class="bold"><strong>prepared backup</strong></span>. The changes
        are recorded in the
        <span class="bold"><strong>ibbackup_logfile</strong></span> file; once the
        apply step is finished, this file is no longer necessary.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_ibbackup_logfile">ibbackup_logfile</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_prepared_backup">prepared backup</a>, <a class="glossseealso" href="glossary.html#glos_raw_backup">raw backup</a>.</p></dd><dt><a name="glos_asynchronous_io"></a><span class="glossterm">asynchronous I/O</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397266672"></a>
        A type of I/O operation that allows other processing to proceed
        before the I/O is completed. Also known as
        <span class="bold"><strong>nonblocking I/O</strong></span> and abbreviated
        as <span class="bold"><strong>AIO</strong></span>.
        <code class="literal">InnoDB</code> uses this type of I/O for certain
        operations that can run in parallel without affecting the
        reliability of the database, such as reading pages into the
        <span class="bold"><strong>buffer pool</strong></span> that have not
        actually been requested, but might be needed soon.
      </p><p>
        Historically, <code class="literal">InnoDB</code> used asynchronous I/O on
        Windows systems only. Starting with the InnoDB Plugin 1.1 and
        MySQL 5.5, <code class="literal">InnoDB </code>uses asynchronous I/O on
        Linux systems. This change introduces a dependency on
        <code class="literal">libaio</code>. Asynchronous I/O on Linux systems is
        configured using the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_use_native_aio"><code class="literal">innodb_use_native_aio</code></a> option,
        which is enabled by default. On other Unix-like systems, InnoDB
        uses synchronous I/O only.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_non_blocking_io">nonblocking I/O</a>.</p></dd><dt><a name="glos_atomic"></a><span class="glossterm">atomic</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397256048"></a>
        In the SQL context,
        <span class="bold"><strong>transactions</strong></span> are units of work
        that either succeed entirely (when
        <span class="bold"><strong>committed</strong></span>) or have no effect at
        all (when <span class="bold"><strong>rolled back</strong></span>). The
        indivisible ("atomic") property of transactions is the
        <span class="quote">“<span class="quote">A</span>”</span> in the acronym
        <span class="bold"><strong>ACID</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_atomic_ddl"></a><span class="glossterm">atomic DDL</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397248464"></a>
        An atomic <span class="emphasis"><em>DDL</em></span> statement is one that
        combines the <span class="emphasis"><em>data dictionary</em></span> updates,
        <span class="emphasis"><em>storage engine</em></span> operations, and
        <span class="emphasis"><em>binary log</em></span> writes associated with a DDL
        operation into a single, atomic transaction. The transaction is
        either fully committed or rolled back, even if the server halts
        during the operation. Atomic DDL support was added in MySQL 8.0.
        For more information, see <a class="xref" href="sql-syntax.html#atomic-ddl" title="13.1.1 Atomic Data Definition Statement Support">Section 13.1.1, “Atomic Data Definition Statement Support”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_binary_log">binary log</a>, <a class="glossseealso" href="glossary.html#glos_data_dictionary">data dictionary</a>, <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_storage_engine">storage engine</a>.</p></dd><dt><a name="glos_atomic_instruction"></a><span class="glossterm">atomic instruction</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397241584"></a>
        Special instructions provided by the CPU, to ensure that
        critical low-level operations cannot be interrupted.
      </p></dd><dt><a name="glos_auto_increment"></a><span class="glossterm">auto-increment</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397239392"></a>
        A property of a table column (specified by the
        <code class="literal">AUTO_INCREMENT</code> keyword) that automatically
        adds an ascending sequence of values in the column.
      </p><p>
        It saves work for the developer, not to have to produce new
        unique values when inserting new rows. It provides useful
        information for the query optimizer, because the column is known
        to be not null and with unique values. The values from such a
        column can be used as lookup keys in various contexts, and
        because they are auto-generated there is no reason to ever
        change them; for this reason, primary key columns are often
        specified as auto-incrementing.
      </p><p>
        Auto-increment columns can be problematic with statement-based
        replication, because replaying the statements on a slave might
        not produce the same set of column values as on the master, due
        to timing issues. When you have an auto-incrementing primary
        key, you can use statement-based replication only with the
        setting
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode=1</code></a>. If
        you have
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode=2</code></a>,
        which allows higher concurrency for insert operations, use
        <span class="bold"><strong>row-based replication</strong></span> rather
        than <span class="bold"><strong>statement-based
        replication</strong></span>. The setting
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode=0</code></a>
        should not be used except for compatibility purposes.
      </p><p>
        Consecutive lock mode
        (<a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode=1</code></a>) is
        the default setting prior to MySQL 8.0.3. As of MySQL 8.0.3,
        interleaved lock mode
        (<a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode=2</code></a>) is
        the default, which reflects the change from statement-based to
        row-based replication as the default replication type.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_auto_increment_locking">auto-increment locking</a>, <a class="glossseealso" href="glossary.html#glos_innodb_autoinc_lock_mode">innodb_autoinc_lock_mode</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>, <a class="glossseealso" href="glossary.html#glos_row_based_replication">row-based replication</a>, <a class="glossseealso" href="glossary.html#glos_statement_based_replication">statement-based replication</a>.</p></dd><dt><a name="glos_auto_increment_locking"></a><span class="glossterm">auto-increment locking</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397222768"></a>
        The convenience of an
        <span class="bold"><strong>auto-increment</strong></span> primary key
        involves some tradeoff with concurrency. In the simplest case,
        if one transaction is inserting values into the table, any other
        transactions must wait to do their own inserts into that table,
        so that rows inserted by the first transaction receive
        consecutive primary key values. <code class="literal">InnoDB</code>
        includes optimizations and the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode</code></a> option
        so that you can configure and optimal balance between
        predictable sequences of auto-increment values and maximum
        <span class="bold"><strong>concurrency</strong></span> for insert
        operations.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_auto_increment">auto-increment</a>, <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_innodb_autoinc_lock_mode">innodb_autoinc_lock_mode</a>.</p></dd><dt><a name="glos_autocommit"></a><span class="glossterm">autocommit</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397215168"></a>
        A setting that causes a <span class="bold"><strong>commit</strong></span>
        operation after each <span class="bold"><strong>SQL</strong></span>
        statement. This mode is not recommended for working with
        <code class="literal">InnoDB</code> tables with
        <span class="bold"><strong>transactions</strong></span> that span several
        statements. It can help performance for
        <span class="bold"><strong>read-only transactions</strong></span> on
        <code class="literal">InnoDB</code> tables, where it minimizes overhead
        from <span class="bold"><strong>locking</strong></span> and generation of
        <span class="bold"><strong>undo</strong></span> data, especially in MySQL
        5.6.4 and up. It is also appropriate for working with
        <a class="link" href="storage-engines.html#myisam-storage-engine" title="16.2 The MyISAM Storage Engine"><code class="literal">MyISAM</code></a> tables, where transactions
        are not applicable.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_read_only_transaction">read-only transaction</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>, <a class="glossseealso" href="glossary.html#glos_undo">undo</a>.</p></dd><dt><a name="glos_availability"></a><span class="glossterm">availability</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397202464"></a>
        The ability to cope with, and if necessary recover from,
        failures on the host, including failures of MySQL, the operating
        system, or the hardware and maintenance activity that may
        otherwise cause downtime. Often paired with
        <span class="bold"><strong>scalability</strong></span> as critical aspects
        of a large-scale deployment.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_scalability">scalability</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">B</h3>
<dl><dt><a name="glos_b_tree"></a><span class="glossterm">B-tree</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397198224"></a>
        A tree data structure that is popular for use in database
        indexes. The structure is kept sorted at all times, enabling
        fast lookup for exact matches (equals operator) and ranges (for
        example, greater than, less than, and <code class="literal">BETWEEN</code>
        operators). This type of index is available for most storage
        engines, such as <a class="link" href="innodb-storage-engine.html" title="Chapter 15 The InnoDB Storage Engine"><code class="literal">InnoDB</code></a> and
        <a class="link" href="storage-engines.html#myisam-storage-engine" title="16.2 The MyISAM Storage Engine"><code class="literal">MyISAM</code></a>.
      </p><p>
        Because B-tree nodes can have many children, a B-tree is not the
        same as a binary tree, which is limited to 2 children per node.
      </p><p>
        Contrast with <span class="bold"><strong>hash index</strong></span>, which
        is only available in the <a class="link" href="storage-engines.html#memory-storage-engine" title="16.3 The MEMORY Storage Engine"><code class="literal">MEMORY</code></a>
        storage engine. The <code class="literal">MEMORY</code> storage engine can
        also use B-tree indexes, and you should choose B-tree indexes
        for <code class="literal">MEMORY</code> tables if some queries use range
        operators.
      </p><p>
        The use of the term B-tree is intended as a reference to the
        general class of index design. B-tree structures used by MySQL
        storage engines may be regarded as variants due to
        sophistications not present in a classic B-tree design. For
        related information, refer to the <code class="literal">InnoDB</code> Page
        Structure
        <a class="ulink" href="https://dev.mysql.com/doc/internals/en/innodb-fil-header.html" target="_top">Fil
        Header</a> section of the
        <a class="ulink" href="https://dev.mysql.com/doc/internals/en/index.html" target="_top">MySQL
        Internals Manual</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_hash_index">hash index</a>.</p></dd><dt><a name="glos_backticks"></a><span class="glossterm">backticks</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397184544"></a>
        Identifiers within MySQL SQL statements must be quoted using the
        backtick character (<code class="literal">`</code>) if they contain
        special characters or reserved words. For example, to refer to a
        table named <code class="literal">FOO#BAR</code> or a column named
        <code class="literal">SELECT</code>, you would specify the identifiers as
        <code class="literal">`FOO#BAR`</code> and <code class="literal">`SELECT`</code>.
        Since the backticks provide an extra level of safety, they are
        used extensively in program-generated SQL statements, where the
        identifier names might not be known in advance.
      </p><p>
        Many other database systems use double quotation marks
        (<code class="literal">"</code>) around such special names. For
        portability, you can enable <code class="literal">ANSI_QUOTES</code> mode
        in MySQL and use double quotation marks instead of backticks to
        qualify identifier names.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>.</p></dd><dt><a name="glos_backup"></a><span class="glossterm">backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397175952"></a>
        The process of copying some or all table data and metadata from
        a MySQL instance, for safekeeping. Can also refer to the set of
        copied files. This is a crucial task for DBAs. The reverse of
        this process is the <span class="bold"><strong>restore</strong></span>
        operation.
      </p><p>
        With MySQL, <span class="bold"><strong>physical backups</strong></span>
        are performed by the <span class="bold"><strong>MySQL Enterprise
        Backup</strong></span> product, and <span class="bold"><strong>logical
        backups</strong></span> are performed by the
        <code class="literal">mysqldump</code> command. These techniques have
        different characteristics in terms of size and representation of
        the backup data, and speed (especially speed of the restore
        operation).
      </p><p>
        Backups are further classified as
        <span class="bold"><strong>hot</strong></span>,
        <span class="bold"><strong>warm</strong></span>, or
        <span class="bold"><strong>cold</strong></span> depending on how much they
        interfere with normal database operation. (Hot backups have the
        least interference, cold backups the most.)
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_cold_backup">cold backup</a>, <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_logical_backup">logical backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_mysqldump">mysqldump</a>, <a class="glossseealso" href="glossary.html#glos_physical_backup">physical backup</a>, <a class="glossseealso" href="glossary.html#glos_warm_backup">warm backup</a>.</p></dd><dt><a name="glos_base_column"></a><span class="glossterm">base column</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397162832"></a>
        A non-generated table column upon which a stored generated
        column or virtual generated column is based. In other words, a
        base column is a non-generated table column that is part of a
        generated column definition.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_generated_column">generated column</a>, <a class="glossseealso" href="glossary.html#glos_stored_generated_column">stored generated column</a>, <a class="glossseealso" href="glossary.html#glos_virtual_generated_column">virtual generated column</a>.</p></dd><dt><a name="glos_beta"></a><span class="glossterm">beta</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397158928"></a>
        An early stage in the life of a software product, when it is
        available only for evaluation, typically without a definite
        release number or a number less than 1.
        <code class="literal">InnoDB</code> does not use the beta designation,
        preferring an <span class="bold"><strong>early adopter</strong></span>
        phase that can extend over several point releases, leading to a
        <span class="bold"><strong>GA</strong></span> release.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_early_adopter">early adopter</a>, <a class="glossseealso" href="glossary.html#glos_ga">GA</a>.</p></dd><dt><a name="glos_binary_log"></a><span class="glossterm">binary log</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397153184"></a>
        A file containing a record of all statements that attempt to
        change table data. These statements can be replayed to bring
        slave servers up to date in a
        <span class="bold"><strong>replication</strong></span> scenario, or to
        bring a database up to date after restoring table data from a
        backup. The binary logging feature can be turned on and off,
        although Oracle recommends always enabling it if you use
        replication or perform backups.
      </p><p>
        You can examine the contents of the binary log, or replay those
        statements during replication or recovery, by using the
        <a class="link" href="programs.html#mysqlbinlog" title="4.6.8 mysqlbinlog — Utility for Processing Binary Log Files"><span class="command"><strong>mysqlbinlog</strong></span></a> command. For full information
        about the binary log, see <a class="xref" href="server-administration.html#binary-log" title="5.4.4 The Binary Log">Section 5.4.4, “The Binary Log”</a>. For
        MySQL configuration options related to the binary log, see
        <a class="xref" href="replication.html#replication-options-binary-log" title="17.1.6.4 Binary Logging Options and Variables">Section 17.1.6.4, “Binary Logging Options and Variables”</a>.
      </p><p>
        For the <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product, the file name of the binary log and the current
        position within the file are important details. To record this
        information for the master server when taking a backup in a
        replication context, you can specify the
        <code class="literal">--slave-info</code> option.
      </p><p>
        Prior to MySQL 5.0, a similar capability was available, known as
        the update log. In MySQL 5.0 and higher, the binary log replaces
        the update log.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_binlog">binlog</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_replication">replication</a>.</p></dd><dt><a name="glos_binlog"></a><span class="glossterm">binlog</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397142224"></a>
        An informal name for the <span class="bold"><strong>binary
        log</strong></span> file. For example, you might see this
        abbreviation used in e-mail messages or forum discussions.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_binary_log">binary log</a>.</p></dd><dt><a name="glos_blind_query_expansion"></a><span class="glossterm">blind query expansion</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397138736"></a>
        A special mode of <span class="bold"><strong>full-text
        search</strong></span> enabled by the <code class="literal">WITH QUERY
        EXPANSION</code> clause. It performs the search twice, where
        the search phrase for the second search is the original search
        phrase concatenated with the few most highly relevant documents
        from the first search. This technique is mainly applicable for
        short search phrases, perhaps only a single word. It can uncover
        relevant matches where the precise search term does not occur in
        the document.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_full_text_search">full-text search</a>.</p></dd><dt><a name="glos_bottleneck"></a><span class="glossterm">bottleneck</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397134176"></a>
        A portion of a system that is constrained in size or capacity,
        that has the effect of limiting overall throughput. For example,
        a memory area might be smaller than necessary; access to a
        single required resource might prevent multiple CPU cores from
        running simultaneously; or waiting for disk I/O to complete
        might prevent the CPU from running at full capacity. Removing
        bottlenecks tends to improve
        <span class="bold"><strong>concurrency</strong></span>. For example, the
        ability to have multiple <code class="literal">InnoDB</code>
        <span class="bold"><strong>buffer pool</strong></span> instances reduces
        contention when multiple sessions read from and write to the
        buffer pool simultaneously.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>.</p></dd><dt><a name="glos_bounce"></a><span class="glossterm">bounce</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397128304"></a>
        A <span class="bold"><strong>shutdown</strong></span> operation
        immediately followed by a restart. Ideally with a relatively
        short <span class="bold"><strong>warmup</strong></span> period so that
        performance and throughput quickly return to a high level.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_shutdown">shutdown</a>.</p></dd><dt><a name="glos_buddy_allocator"></a><span class="glossterm">buddy allocator</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397124176"></a>
        A mechanism for managing different-sized
        <span class="bold"><strong>pages</strong></span> in the InnoDB
        <span class="bold"><strong>buffer pool</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_page_size">page size</a>.</p></dd><dt><a name="glos_buffer"></a><span class="glossterm">buffer</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397119088"></a>
        A memory or disk area used for temporary storage. Data is
        buffered in memory so that it can be written to disk
        efficiently, with a few large I/O operations rather than many
        small ones. Data is buffered on disk for greater reliability, so
        that it can be recovered even when a
        <span class="bold"><strong>crash</strong></span> or other failure occurs
        at the worst possible time. The main types of buffers used by
        InnoDB are the <span class="bold"><strong>buffer pool</strong></span>, the
        <span class="bold"><strong>doublewrite buffer</strong></span>, and the
        <span class="bold"><strong>change buffer</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_change_buffer">change buffer</a>, <a class="glossseealso" href="glossary.html#glos_crash">crash</a>, <a class="glossseealso" href="glossary.html#glos_doublewrite_buffer">doublewrite buffer</a>.</p></dd><dt><a name="glos_buffer_pool"></a><span class="glossterm">buffer pool</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397111504"></a>
        The memory area that holds cached <code class="literal">InnoDB</code> data
        for both tables and indexes. For efficiency of high-volume read
        operations, the buffer pool is divided into
        <span class="bold"><strong>pages</strong></span> that can potentially hold
        multiple rows. For efficiency of cache management, the buffer
        pool is implemented as a linked list of pages; data that is
        rarely used is aged out of the cache, using a variation of the
        <span class="bold"><strong>LRU</strong></span> algorithm. On systems with
        large memory, you can improve concurrency by dividing the buffer
        pool into multiple <span class="bold"><strong>buffer pool
        instances</strong></span>.
      </p><p>
        Several <code class="literal">InnoDB</code> status variables,
        <code class="literal">INFORMATION_SCHEMA</code> tables, and
        <code class="literal">performance_schema</code> tables help to monitor the
        internal workings of the buffer pool. Starting in MySQL 5.6, you
        can avoid a lengthy warmup period after restarting the server,
        particularly for instances with large buffer pools, by saving
        the buffer pool state at server shutdown and restoring the
        buffer pool to the same state at server startup. See
        <a class="xref" href="innodb-storage-engine.html#innodb-preload-buffer-pool" title="15.6.3.8 Saving and Restoring the Buffer Pool State">Section 15.6.3.8, “Saving and Restoring the Buffer Pool State”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool_instance">buffer pool instance</a>, <a class="glossseealso" href="glossary.html#glos_lru">LRU</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_warm_up">warm up</a>.</p></dd><dt><a name="glos_buffer_pool_instance"></a><span class="glossterm">buffer pool instance</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397100240"></a>
        Any of the multiple regions into which the
        <span class="bold"><strong>buffer pool</strong></span> can be divided,
        controlled by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_buffer_pool_instances"><code class="literal">innodb_buffer_pool_instances</code></a>
        configuration option. The total memory size specified by
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_buffer_pool_size"><code class="literal">innodb_buffer_pool_size</code></a> is
        divided among all buffer pool instances. Typically, having
        multiple buffer pool instances is appropriate for systems that
        allocate multiple gigabytes to the <code class="literal">InnoDB</code>
        buffer pool, with each instance being one gigabyte or larger. On
        systems loading or looking up large amounts of data in the
        buffer pool from many concurrent sessions, having multiple
        buffer pool instances reduces contention for exclusive access to
        data structures that manage the buffer pool.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>.</p></dd><dt><a name="glos_built_in"></a><span class="glossterm">built-in</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397092672"></a>
        The built-in <code class="literal">InnoDB</code> storage engine within
        MySQL is the original form of distribution for the storage
        engine. Contrast with the <span class="bold"><strong>InnoDB
        Plugin</strong></span>. Starting with MySQL 5.5, the InnoDB Plugin is
        merged back into the MySQL code base as the built-in
        <code class="literal">InnoDB</code> storage engine (known as InnoDB 1.1).
      </p><p>
        This distinction is important mainly in MySQL 5.1, where a
        feature or bug fix might apply to the InnoDB Plugin but not the
        built-in <code class="literal">InnoDB</code>, or vice versa.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>.</p></dd><dt><a name="glos_business_rules"></a><span class="glossterm">business rules</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397086352"></a>
        The relationships and sequences of actions that form the basis
        of business software, used to run a commercial company.
        Sometimes these rules are dictated by law, other times by
        company policy. Careful planning ensures that the relationships
        encoded and enforced by the database, and the actions performed
        through application logic, accurately reflect the real policies
        of the company and can handle real-life situations.
      </p><p>
        For example, an employee leaving a company might trigger a
        sequence of actions from the human resources department. The
        human resources database might also need the flexibility to
        represent data about a person who has been hired, but not yet
        started work. Closing an account at an online service might
        result in data being removed from a database, or the data might
        be moved or flagged so that it could be recovered if the account
        is re-opened. A company might establish policies regarding
        salary maximums, minimums, and adjustments, in addition to basic
        sanity checks such as the salary not being a negative number. A
        retail database might not allow a purchase with the same serial
        number to be returned more than once, or might not allow credit
        card purchases above a certain value, while a database used to
        detect fraud might allow these kinds of things.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_relational">relational</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">C</h3>
<dl><dt><a name="glos_cfg_file"></a><span class="glossterm">.cfg file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397060752"></a>
        A metadata file used with the <code class="literal">InnoDB</code>
        <span class="bold"><strong>transportable tablespace</strong></span>
        feature. It is produced by the command <code class="literal">FLUSH TABLES ...
        FOR EXPORT</code>, puts one or more tables in a consistent
        state that can be copied to another server. The
        <code class="literal">.cfg</code> file is copied along with the
        corresponding <span class="bold"><strong>.ibd file</strong></span>, and
        used to adjust the internal values of the
        <code class="literal">.ibd</code> file, such as the
        <span class="bold"><strong>space ID</strong></span>, during the
        <code class="literal">ALTER TABLE ... IMPORT TABLESPACE</code> step.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_space_id">space ID</a>, <a class="glossseealso" href="glossary.html#glos_transportable_tablespace">transportable tablespace</a>.</p></dd><dt><a name="glos_cache"></a><span class="glossterm">cache</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397081248"></a>
        The general term for any memory area that stores copies of data
        for frequent or high-speed retrieval. In
        <code class="literal">InnoDB</code>, the primary kind of cache structure
        is the <span class="bold"><strong>buffer pool</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer">buffer</a>, <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>.</p></dd><dt><a name="glos_cardinality"></a><span class="glossterm">cardinality</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397076496"></a>
        The number of different values in a table
        <span class="bold"><strong>column</strong></span>. When queries refer to
        columns that have an associated
        <span class="bold"><strong>index</strong></span>, the cardinality of each
        column influences which access method is most efficient. For
        example, for a column with a <span class="bold"><strong>unique
        constraint</strong></span>, the number of different values is equal
        to the number of rows in the table. If a table has a million
        rows but only 10 different values for a particular column, each
        value occurs (on average) 100,000 times. A query such as
        <code class="literal">SELECT c1 FROM t1 WHERE c1 = 50;</code> thus might
        return 1 row or a huge number of rows, and the database server
        might process the query differently depending on the cardinality
        of <code class="literal">c1</code>.
      </p><p>
        If the values in a column have a very uneven distribution, the
        cardinality might not be a good way to determine the best query
        plan. For example, <code class="literal">SELECT c1 FROM t1 WHERE c1 =
        x;</code> might return 1 row when <code class="literal">x=50</code> and
        a million rows when <code class="literal">x=30</code>. In such a case, you
        might need to use <span class="bold"><strong>index hints</strong></span>
        to pass along advice about which lookup method is more efficient
        for a particular query.
      </p><p>
        Cardinality can also apply to the number of distinct values
        present in multiple columns, as in a
        <span class="bold"><strong>composite index</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_column">column</a>, <a class="glossseealso" href="glossary.html#glos_composite_index">composite index</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_index_hint">index hint</a>, <a class="glossseealso" href="glossary.html#glos_persistent_statistics">persistent statistics</a>, <a class="glossseealso" href="glossary.html#glos_random_dive">random dive</a>, <a class="glossseealso" href="glossary.html#glos_selectivity">selectivity</a>, <a class="glossseealso" href="glossary.html#glos_unique_constraint">unique constraint</a>.</p></dd><dt><a name="glos_change_buffer"></a><span class="glossterm">change buffer</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397050720"></a>
        A special data structure that records changes to
        <span class="bold"><strong>pages</strong></span> in
        <span class="bold"><strong>secondary indexes</strong></span>. These values
        could result from SQL <a class="link" href="sql-syntax.html#insert" title="13.2.6 INSERT Syntax"><code class="literal">INSERT</code></a>,
        <a class="link" href="sql-syntax.html#update" title="13.2.12 UPDATE Syntax"><code class="literal">UPDATE</code></a>, or
        <a class="link" href="sql-syntax.html#delete" title="13.2.2 DELETE Syntax"><code class="literal">DELETE</code></a> statements
        (<span class="bold"><strong>DML</strong></span>). The set of features
        involving the change buffer is known collectively as
        <span class="bold"><strong>change buffering</strong></span>, consisting of
        <span class="bold"><strong>insert buffering</strong></span>,
        <span class="bold"><strong>delete buffering</strong></span>, and
        <span class="bold"><strong>purge buffering</strong></span>.
      </p><p>
        Changes are only recorded in the change buffer when the relevant
        page from the secondary index is not in the
        <span class="bold"><strong>buffer pool</strong></span>. When the relevant
        index page is brought into the buffer pool while associated
        changes are still in the change buffer, the changes for that
        page are applied in the buffer pool
        (<span class="bold"><strong>merged</strong></span>) using the data from
        the change buffer. Periodically, the
        <span class="bold"><strong>purge</strong></span> operation that runs
        during times when the system is mostly idle, or during a slow
        shutdown, writes the new index pages to disk. The purge
        operation can write the disk blocks for a series of index values
        more efficiently than if each value were written to disk
        immediately.
      </p><p>
        Physically, the change buffer is part of the
        <span class="bold"><strong>system tablespace</strong></span>, so that the
        index changes remain buffered across database restarts. The
        changes are only applied
        (<span class="bold"><strong>merged</strong></span>) when the pages are
        brought into the buffer pool due to some other read operation.
      </p><p>
        The kinds and amount of data stored in the change buffer are
        governed by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_change_buffering"><code class="literal">innodb_change_buffering</code></a> and
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_change_buffer_max_size"><code class="literal">innodb_change_buffer_max_size</code></a>
        configuration options. To see information about the current data
        in the change buffer, issue the
        <a class="link" href="sql-syntax.html#show-engine" title="13.7.6.15 SHOW ENGINE Syntax"><code class="literal">SHOW ENGINE INNODB
        STATUS</code></a> command.
      </p><p>
        Formerly known as the <span class="bold"><strong>insert
        buffer</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_change_buffering">change buffering</a>, <a class="glossseealso" href="glossary.html#glos_delete_buffering">delete buffering</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_insert_buffer">insert buffer</a>, <a class="glossseealso" href="glossary.html#glos_insert_buffering">insert buffering</a>, <a class="glossseealso" href="glossary.html#glos_merge">merge</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_purge">purge</a>, <a class="glossseealso" href="glossary.html#glos_purge_buffering">purge buffering</a>, <a class="glossseealso" href="glossary.html#glos_secondary_index">secondary index</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>.</p></dd><dt><a name="glos_change_buffering"></a><span class="glossterm">change buffering</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397022320"></a>
        The general term for the features involving the
        <span class="bold"><strong>change buffer</strong></span>, consisting of
        <span class="bold"><strong>insert buffering</strong></span>,
        <span class="bold"><strong>delete buffering</strong></span>, and
        <span class="bold"><strong>purge buffering</strong></span>. Index changes
        resulting from SQL statements, which could normally involve
        random I/O operations, are held back and performed periodically
        by a background <span class="bold"><strong>thread</strong></span>. This
        sequence of operations can write the disk blocks for a series of
        index values more efficiently than if each value were written to
        disk immediately. Controlled by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_change_buffering"><code class="literal">innodb_change_buffering</code></a> and
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_change_buffer_max_size"><code class="literal">innodb_change_buffer_max_size</code></a>
        configuration options.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_change_buffer">change buffer</a>, <a class="glossseealso" href="glossary.html#glos_delete_buffering">delete buffering</a>, <a class="glossseealso" href="glossary.html#glos_insert_buffering">insert buffering</a>, <a class="glossseealso" href="glossary.html#glos_purge_buffering">purge buffering</a>.</p></dd><dt><a name="glos_checkpoint"></a><span class="glossterm">checkpoint</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397011680"></a>
        As changes are made to data pages that are cached in the
        <span class="bold"><strong>buffer pool</strong></span>, those changes are
        written to the <span class="bold"><strong>data files</strong></span>
        sometime later, a process known as
        <span class="bold"><strong>flushing</strong></span>. The checkpoint is a
        record of the latest changes (represented by an
        <span class="bold"><strong>LSN</strong></span> value) that have been
        successfully written to the data files.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_fuzzy_checkpointing">fuzzy checkpointing</a>, <a class="glossseealso" href="glossary.html#glos_lsn">LSN</a>.</p></dd><dt><a name="glos_checksum"></a><span class="glossterm">checksum</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899397003952"></a>
        In <code class="literal">InnoDB</code>, a validation mechanism to detect
        corruption when a <span class="bold"><strong>page</strong></span> in a
        <span class="bold"><strong>tablespace</strong></span> is read from disk
        into the <code class="literal">InnoDB</code> <span class="bold"><strong>buffer
        pool</strong></span>. This feature is controlled by the
        <a class="ulink" href="http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_checksums" target="_top"><code class="literal">innodb_checksums</code></a> configuration
        option in MySQL 5.5.
        <a class="ulink" href="http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_checksums" target="_top"><code class="literal">innodb_checksums</code></a> is deprecated
        in MySQL 5.6.3, replaced by
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_checksum_algorithm"><code class="literal">innodb_checksum_algorithm</code></a>.
      </p><p>
        The <a class="link" href="programs.html#innochecksum" title="4.6.2 innochecksum — Offline InnoDB File Checksum Utility"><span class="command"><strong>innochecksum</strong></span></a> command helps diagnose
        corruption problems by testing the checksum values for a
        specified <span class="bold"><strong>tablespace</strong></span> file while
        the MySQL server is shut down.
      </p><p>
        MySQL also uses checksums for replication purposes. For details,
        see the configuration options
        <a class="link" href="replication.html#sysvar_binlog_checksum"><code class="literal">binlog_checksum</code></a>,
        <a class="link" href="replication.html#sysvar_master_verify_checksum"><code class="literal">master_verify_checksum</code></a>, and
        <a class="link" href="replication.html#sysvar_slave_sql_verify_checksum"><code class="literal">slave_sql_verify_checksum</code></a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>.</p></dd><dt><a name="glos_child_table"></a><span class="glossterm">child table</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396986192"></a>
        In a <span class="bold"><strong>foreign key</strong></span> relationship,
        a child table is one whose rows refer (or point) to rows in
        another table with an identical value for a specific column.
        This is the table that contains the <code class="literal">FOREIGN KEY ...
        REFERENCES</code> clause and optionally <code class="literal">ON
        UPDATE</code> and <code class="literal">ON DELETE</code> clauses. The
        corresponding row in the <span class="bold"><strong>parent
        table</strong></span> must exist before the row can be created in the
        child table. The values in the child table can prevent delete or
        update operations on the parent table, or can cause automatic
        deletion or updates in the child table, based on the <code class="literal">ON
        CASCADE</code> option used when creating the foreign key.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_foreign_key">foreign key</a>, <a class="glossseealso" href="glossary.html#glos_parent_table">parent table</a>.</p></dd><dt><a name="glos_clean_page"></a><span class="glossterm">clean page</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396978288"></a>
        A <span class="bold"><strong>page</strong></span> in the
        <code class="literal">InnoDB</code> <span class="bold"><strong>buffer
        pool</strong></span> where all changes made in memory have also been
        written (<span class="bold"><strong>flushed</strong></span>) to the
        <a class="link" href="glossary.html#glos_data_files" title="data files">data files</a>. The opposite
        of a <span class="bold"><strong>dirty page</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_dirty_page">dirty page</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>.</p></dd><dt><a name="glos_clean_shutdown"></a><span class="glossterm">clean shutdown</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396969136"></a>
        A <span class="bold"><strong>shutdown</strong></span> that completes
        without errors and applies all changes to
        <code class="literal">InnoDB</code> tables before finishing, as opposed to
        a <span class="bold"><strong>crash</strong></span> or a
        <span class="bold"><strong>fast shutdown</strong></span>. Synonym for
        <span class="bold"><strong>slow shutdown</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_crash">crash</a>, <a class="glossseealso" href="glossary.html#glos_fast_shutdown">fast shutdown</a>, <a class="glossseealso" href="glossary.html#glos_shutdown">shutdown</a>, <a class="glossseealso" href="glossary.html#glos_slow_shutdown">slow shutdown</a>.</p></dd><dt><a name="glos_client"></a><span class="glossterm">client</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396961328"></a>
        A type of program that sends requests to a
        <span class="bold"><strong>server</strong></span>, and interprets or
        processes the results. The client software might run only some
        of the time (such as a mail or chat program), and might run
        interactively (such as the <a class="link" href="programs.html#mysql" title="4.5.1 mysql — The MySQL Command-Line Tool"><span class="command"><strong>mysql</strong></span></a> command
        processor).
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_mysql">mysql</a>, <a class="glossseealso" href="glossary.html#glos_server">server</a>.</p></dd><dt><a name="glos_clustered_index"></a><span class="glossterm">clustered index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396955680"></a>
        The <code class="literal">InnoDB</code> term for a
        <span class="bold"><strong>primary key</strong></span> index.
        <code class="literal">InnoDB</code> table storage is organized based on
        the values of the primary key columns, to speed up queries and
        sorts involving the primary key columns. For best performance,
        choose the primary key columns carefully based on the most
        performance-critical queries. Because modifying the columns of
        the clustered index is an expensive operation, choose primary
        columns that are rarely or never updated.
      </p><p>
        In the Oracle Database product, this type of table is known as
        an <span class="bold"><strong>index-organized table</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>, <a class="glossseealso" href="glossary.html#glos_secondary_index">secondary index</a>.</p></dd><dt><a name="glos_cold_backup"></a><span class="glossterm">cold backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396948336"></a>
        A <span class="bold"><strong>backup</strong></span> taken while the
        database is shut down. For busy applications and websites, this
        might not be practical, and you might prefer a
        <span class="bold"><strong>warm backup</strong></span> or a
        <span class="bold"><strong>hot backup</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_backup">backup</a>, <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_warm_backup">warm backup</a>.</p></dd><dt><a name="glos_column"></a><span class="glossterm">column</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396942352"></a>
        A data item within a <span class="bold"><strong>row</strong></span>, whose
        storage and semantics are defined by a data type. Each
        <span class="bold"><strong>table</strong></span> and
        <span class="bold"><strong>index</strong></span> is largely defined by the
        set of columns it contains.
      </p><p>
        Each column has a <span class="bold"><strong>cardinality</strong></span>
        value. A column can be the <span class="bold"><strong>primary
        key</strong></span> for its table, or part of the primary key. A
        column can be subject to a <span class="bold"><strong>unique
        constraint</strong></span>, a <span class="bold"><strong>NOT NULL
        constraint</strong></span>, or both. Values in different columns,
        even across different tables, can be linked by a
        <span class="bold"><strong>foreign key</strong></span> relationship.
      </p><p>
        In discussions of MySQL internal operations, sometimes
        <span class="bold"><strong>field</strong></span> is used as a synonym.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_cardinality">cardinality</a>, <a class="glossseealso" href="glossary.html#glos_foreign_key">foreign key</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_not_null_constraint">NOT NULL constraint</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>, <a class="glossseealso" href="glossary.html#glos_row">row</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>, <a class="glossseealso" href="glossary.html#glos_unique_constraint">unique constraint</a>.</p></dd><dt><a name="glos_column_index"></a><span class="glossterm">column index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396927984"></a>
        An <span class="bold"><strong>index</strong></span> on a single column.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_composite_index">composite index</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>.</p></dd><dt><a name="glos_column_prefix"></a><span class="glossterm">column prefix</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396924144"></a>
        When an <span class="bold"><strong>index</strong></span> is created with a
        length specification, such as <code class="literal">CREATE INDEX idx ON t1
        (c1(N))</code>, only the first N characters of the column
        value are stored in the index. Keeping the index prefix small
        makes the index compact, and the memory and disk I/O savings
        help performance. (Although making the index prefix too small
        can hinder query optimization by making rows with different
        values appear to the query optimizer to be duplicates.)
      </p><p>
        For columns containing binary values or long text strings, where
        sorting is not a major consideration and storing the entire
        value in the index would waste space, the index automatically
        uses the first N (typically 768) characters of the value to do
        lookups and sorts.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_index">index</a>.</p></dd><dt><a name="glos_commit"></a><span class="glossterm">commit</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396918960"></a>
        A <span class="bold"><strong>SQL</strong></span> statement that ends a
        <span class="bold"><strong>transaction</strong></span>, making permanent
        any changes made by the transaction. It is the opposite of
        <span class="bold"><strong>rollback</strong></span>, which undoes any
        changes made in the transaction.
      </p><p>
        <code class="literal">InnoDB</code> uses an
        <span class="bold"><strong>optimistic</strong></span> mechanism for
        commits, so that changes can be written to the data files before
        the commit actually occurs. This technique makes the commit
        itself faster, with the tradeoff that more work is required in
        case of a rollback.
      </p><p>
        By default, MySQL uses the
        <span class="bold"><strong>autocommit</strong></span> setting, which
        automatically issues a commit following each SQL statement.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_autocommit">autocommit</a>, <a class="glossseealso" href="glossary.html#glos_optimistic">optimistic</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_compact_row_format"></a><span class="glossterm">compact row format</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396908800"></a>
        A <span class="bold"><strong>row format</strong></span> for InnoDB tables.
        It was the default row format from MySQL 5.0.3 to MySQL 5.7.8.
        In MySQL 8.0, the default row format is defined by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_default_row_format"><code class="literal">innodb_default_row_format</code></a>
        configuration option, which has a default setting of
        <span class="bold"><strong>DYNAMIC</strong></span>. The
        <span class="bold"><strong>COMPACT</strong></span> row format provides a
        more compact representation for nulls and variable-length
        columns than the <span class="bold"><strong>REDUNDANT</strong></span> row
        format.
      </p><p>
        For additional information about <code class="literal">InnoDB</code>
        <code class="literal">COMPACT</code> row format, see
        <a class="xref" href="innodb-storage-engine.html#innodb-row-format-antelope" title="15.10.4 COMPACT and REDUNDANT Row Formats">Section 15.10.4, “COMPACT and REDUNDANT Row Formats”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_dynamic_row_format">dynamic row format</a>, <a class="glossseealso" href="glossary.html#glos_file_format">file format</a>, <a class="glossseealso" href="glossary.html#glos_redundant_row_format">redundant row format</a>, <a class="glossseealso" href="glossary.html#glos_row_format">row format</a>.</p></dd><dt><a name="glos_composite_index"></a><span class="glossterm">composite index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396897376"></a>
        An <span class="bold"><strong>index</strong></span> that includes multiple
        columns.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_index">index</a>.</p></dd><dt><a name="glos_compressed_backup"></a><span class="glossterm">compressed backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396894032"></a>
        The compression feature of the <span class="bold"><strong>MySQL
        Enterprise Backup</strong></span> product makes a compressed copy of
        each tablespace, changing the extension from
        <code class="literal">.ibd</code> to <code class="literal">.ibz</code>. Compressing
        backup data allows you to keep more backups on hand, and reduces
        the time to transfer backups to a different server. The data is
        uncompressed during the restore operation. When a compressed
        backup operation processes a table that is already compressed,
        it skips the compression step for that table, because
        compressing again would result in little or no space savings.
      </p><p>
        A set of files produced by the <span class="bold"><strong>MySQL
        Enterprise Backup</strong></span> product, where each
        <span class="bold"><strong>tablespace</strong></span> is compressed. The
        compressed files are renamed with a <code class="literal">.ibz</code> file
        extension.
      </p><p>
        Applying <span class="bold"><strong>compression</strong></span> at the
        start of the backup process helps to avoid storage overhead
        during the compression process, and to avoid network overhead
        when transferring the backup files to another server. The
        process of <span class="bold"><strong>applying</strong></span> the
        <span class="bold"><strong>binary log</strong></span> takes longer, and
        requires uncompressing the backup files.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_apply">apply</a>, <a class="glossseealso" href="glossary.html#glos_binary_log">binary log</a>, <a class="glossseealso" href="glossary.html#glos_compression">compression</a>, <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>.</p></dd><dt><a name="glos_compressed_row_format"></a><span class="glossterm">compressed row format</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396880384"></a>
        A <span class="bold"><strong>row format</strong></span> that enables data
        and index <span class="bold"><strong>compression</strong></span> for
        <code class="literal">InnoDB</code> tables. Large fields are stored away
        from the page that holds the rest of the row data, as in
        <span class="bold"><strong>dynamic row format</strong></span>. Both index
        pages and the large fields are compressed, yielding memory and
        disk savings. Depending on the structure of the data, the
        decrease in memory and disk usage might or might not outweigh
        the performance overhead of uncompressing the data as it is
        used. See <a class="xref" href="innodb-storage-engine.html#innodb-compression" title="15.9 InnoDB Table and Page Compression">Section 15.9, “InnoDB Table and Page Compression”</a> for usage
        details.
      </p><p>
        For additional information about <code class="literal">InnoDB</code>
        <code class="literal">COMPRESSED</code> row format, see
        <a class="xref" href="innodb-storage-engine.html#innodb-row-format-dynamic" title="15.10.3 DYNAMIC and COMPRESSED Row Formats">Section 15.10.3, “DYNAMIC and COMPRESSED Row Formats”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_compression">compression</a>, <a class="glossseealso" href="glossary.html#glos_dynamic_row_format">dynamic row format</a>, <a class="glossseealso" href="glossary.html#glos_row_format">row format</a>.</p></dd><dt><a name="glos_compressed_table"></a><span class="glossterm">compressed table</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396870336"></a>
        A table for which the data is stored in compressed form. For
        <code class="literal">InnoDB</code>, it is a table created with
        <code class="literal">ROW_FORMAT=COMPRESSED</code>. See
        <a class="xref" href="innodb-storage-engine.html#innodb-compression" title="15.9 InnoDB Table and Page Compression">Section 15.9, “InnoDB Table and Page Compression”</a> for more information.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_compressed_row_format">compressed row format</a>, <a class="glossseealso" href="glossary.html#glos_compression">compression</a>.</p></dd><dt><a name="glos_compression"></a><span class="glossterm">compression</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396865056"></a>
        A feature with wide-ranging benefits from using less disk space,
        performing less I/O, and using less memory for caching.
      </p><p>
        <code class="literal">InnoDB</code> supports both table-level and
        page-level compression. <code class="literal">InnoDB</code> page
        compression is also referred to as
        <span class="bold"><strong>transparent page compression</strong></span>.
        For more information about <code class="literal">InnoDB</code>
        compression, see <a class="xref" href="innodb-storage-engine.html#innodb-compression" title="15.9 InnoDB Table and Page Compression">Section 15.9, “InnoDB Table and Page Compression”</a>.
      </p><p>
        Another type of compression is the
        <span class="bold"><strong>compressed backup</strong></span> feature of
        the <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_compressed_backup">compressed backup</a>, <a class="glossseealso" href="glossary.html#glos_compressed_row_format">compressed row format</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_transparent_page_compression">transparent page compression</a>.</p></dd><dt><a name="glos_compression_failure"></a><span class="glossterm">compression failure</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396854208"></a>
        Not actually an error, rather an expensive operation that can
        occur when using <span class="bold"><strong>compression</strong></span> in
        combination with <span class="bold"><strong>DML</strong></span>
        operations. It occurs when: updates to a compressed
        <span class="bold"><strong>page</strong></span> overflow the area on the
        page reserved for recording modifications; the page is
        compressed again, with all changes applied to the table data;
        the re-compressed data does not fit on the original page,
        requiring MySQL to split the data into two new pages and
        compress each one separately. To check the frequency of this
        condition, query the
        <a class="link" href="information-schema.html#innodb-cmp-table" title="24.33.5 The INFORMATION_SCHEMA INNODB_CMP and INNODB_CMP_RESET Tables"><code class="literal">INFORMATION_SCHEMA.INNODB_CMP</code></a> table
        and check how much the value of the
        <code class="literal">COMPRESS_OPS</code> column exceeds the value of the
        <code class="literal">COMPRESS_OPS_OK</code> column. Ideally, compression
        failures do not occur often; when they do, you can adjust the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_compression_level"><code class="literal">innodb_compression_level</code></a>,
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_compression_failure_threshold_pct"><code class="literal">innodb_compression_failure_threshold_pct</code></a>,
        and
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_compression_pad_pct_max"><code class="literal">innodb_compression_pad_pct_max</code></a>
        configuration options.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_compression">compression</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>.</p></dd><dt><a name="glos_concatenated_index"></a><span class="glossterm">concatenated index</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_composite_index">composite index</a>.</p></dd><dt><a name="glos_concurrency"></a><span class="glossterm">concurrency</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396839856"></a>
        The ability of multiple operations (in database terminology,
        <span class="bold"><strong>transactions</strong></span>) to run
        simultaneously, without interfering with each other. Concurrency
        is also involved with performance, because ideally the
        protection for multiple simultaneous transactions works with a
        minimum of performance overhead, using efficient mechanisms for
        <span class="bold"><strong>locking</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_configuration_file"></a><span class="glossterm">configuration file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396834512"></a>
        The file that holds the <span class="bold"><strong>option</strong></span>
        values used by MySQL at startup. Traditionally, on Linux and
        Unix this file is named <code class="literal">my.cnf</code>, and on
        Windows it is named <code class="literal">my.ini</code>. You can set a
        number of options related to InnoDB under the
        <code class="literal">[mysqld]</code> section of the file.
      </p><p>
        See <a class="xref" href="programs.html#option-files" title="4.2.6 Using Option Files">Section 4.2.6, “Using Option Files”</a> for information about where
        MySQL searches for configuration files.
      </p><p>
        When you use the <span class="bold"><strong>MySQL Enterprise
        Backup</strong></span> product, you typically use two configuration
        files: one that specifies where the data comes from and how it
        is structured (which could be the original configuration file
        for your server), and a stripped-down one containing only a
        small set of options that specify where the backup data goes and
        how it is structured. The configuration files used with the
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span> product
        must contain certain options that are typically left out of
        regular configuration files, so you might need to add options to
        your existing configuration file for use with
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_my_cnf">my.cnf</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_option">option</a>, <a class="glossseealso" href="glossary.html#glos_option_file">option file</a>.</p></dd><dt><a name="glos_consistent_read"></a><span class="glossterm">consistent read</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396822544"></a>
        A read operation that uses
        <span class="bold"><strong>snapshot</strong></span> information to present
        query results based on a point in time, regardless of changes
        performed by other transactions running at the same time. If
        queried data has been changed by another transaction, the
        original data is reconstructed based on the contents of the
        <span class="bold"><strong>undo log</strong></span>. This technique avoids
        some of the <span class="bold"><strong>locking</strong></span> issues that
        can reduce <span class="bold"><strong>concurrency</strong></span> by
        forcing transactions to wait for other transactions to finish.
      </p><p>
        With <span class="bold"><strong>REPEATABLE READ</strong></span>
        <span class="bold"><strong>isolation level</strong></span>, the snapshot
        is based on the time when the first read operation is performed.
        With <span class="bold"><strong>READ COMMITTED</strong></span> isolation
        level, the snapshot is reset to the time of each consistent read
        operation.
      </p><p>
        Consistent read is the default mode in which
        <code class="literal">InnoDB</code> processes <code class="literal">SELECT</code>
        statements in <span class="bold"><strong>READ COMMITTED</strong></span>
        and <span class="bold"><strong>REPEATABLE READ</strong></span> isolation
        levels. Because a consistent read does not set any locks on the
        tables it accesses, other sessions are free to modify those
        tables while a consistent read is being performed on the table.
      </p><p>
        For technical details about the applicable isolation levels, see
        <a class="xref" href="innodb-storage-engine.html#innodb-consistent-read" title="15.5.2.3 Consistent Nonlocking Reads">Section 15.5.2.3, “Consistent Nonlocking Reads”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_read_committed">READ COMMITTED</a>, <a class="glossseealso" href="glossary.html#glos_repeatable_read">REPEATABLE READ</a>, <a class="glossseealso" href="glossary.html#glos_snapshot">snapshot</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>.</p></dd><dt><a name="glos_constraint"></a><span class="glossterm">constraint</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396805296"></a>
        An automatic test that can block database changes to prevent
        data from becoming inconsistent. (In computer science terms, a
        kind of assertion related to an invariant condition.)
        Constraints are a crucial component of the
        <span class="bold"><strong>ACID</strong></span> philosophy, to maintain
        data consistency. Constraints supported by MySQL include
        <span class="bold"><strong>FOREIGN KEY constraints</strong></span> and
        <span class="bold"><strong>unique constraints</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_foreign_key">foreign key</a>, <a class="glossseealso" href="glossary.html#glos_unique_constraint">unique constraint</a>.</p></dd><dt><a name="glos_counter"></a><span class="glossterm">counter</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396799152"></a>
        A value that is incremented by a particular kind of
        <code class="literal">InnoDB</code> operation. Useful for measuring how
        busy a server is, troubleshooting the sources of performance
        issues, and testing whether changes (for example, to
        configuration settings or indexes used by queries) have the
        desired low-level effects. Different kinds of counters are
        available through <span class="bold"><strong>Performance
        Schema</strong></span> tables and
        <span class="bold"><strong>INFORMATION_SCHEMA</strong></span> tables,
        particularly
        <code class="literal">INFORMATION_SCHEMA.INNODB_METRICS</code>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_information_schema">INFORMATION_SCHEMA</a>, <a class="glossseealso" href="glossary.html#glos_metrics_counter">metrics counter</a>, <a class="glossseealso" href="glossary.html#glos_performance_schema">Performance Schema</a>.</p></dd><dt><a name="glos_covering_index"></a><span class="glossterm">covering index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396792304"></a>
        An <span class="bold"><strong>index</strong></span> that includes all the
        columns retrieved by a query. Instead of using the index values
        as pointers to find the full table rows, the query returns
        values from the index structure, saving disk I/O.
        <code class="literal">InnoDB</code> can apply this optimization technique
        to more indexes than MyISAM can, because
        <code class="literal">InnoDB</code> <span class="bold"><strong>secondary
        indexes</strong></span> also include the
        <span class="bold"><strong>primary key</strong></span> columns.
        <code class="literal">InnoDB</code> cannot apply this technique for
        queries against tables modified by a transaction, until that
        transaction ends.
      </p><p>
        Any <span class="bold"><strong>column index</strong></span> or
        <span class="bold"><strong>composite index</strong></span> could act as a
        covering index, given the right query. Design your indexes and
        queries to take advantage of this optimization technique
        wherever possible.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_column_index">column index</a>, <a class="glossseealso" href="glossary.html#glos_composite_index">composite index</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>, <a class="glossseealso" href="glossary.html#glos_secondary_index">secondary index</a>.</p></dd><dt><a name="glos_cpu_bound"></a><span class="glossterm">CPU-bound</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396780848"></a>
        A type of <span class="bold"><strong>workload</strong></span> where the
        primary <span class="bold"><strong>bottleneck</strong></span> is CPU
        operations in memory. Typically involves read-intensive
        operations where the results can all be cached in the
        <span class="bold"><strong>buffer pool</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_bottleneck">bottleneck</a>, <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_workload">workload</a>.</p></dd><dt><a name="glos_crash"></a><span class="glossterm">crash</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396774928"></a>
        MySQL uses the term <span class="quote">“<span class="quote">crash</span>”</span> to refer generally to
        any unexpected <span class="bold"><strong>shutdown</strong></span>
        operation where the server cannot do its normal cleanup. For
        example, a crash could happen due to a hardware fault on the
        database server machine or storage device; a power failure; a
        potential data mismatch that causes the MySQL server to halt; a
        <span class="bold"><strong>fast shutdown</strong></span> initiated by the
        DBA; or many other reasons. The robust, automatic
        <span class="bold"><strong>crash recovery</strong></span> for
        <span class="bold"><strong>InnoDB</strong></span> tables ensures that data
        is made consistent when the server is restarted, without any
        extra work for the DBA.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_crash_recovery">crash recovery</a>, <a class="glossseealso" href="glossary.html#glos_fast_shutdown">fast shutdown</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_shutdown">shutdown</a>.</p></dd><dt><a name="glos_crash_recovery"></a><span class="glossterm">crash recovery</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396766976"></a>
        The cleanup activities that occur when MySQL is started again
        after a <span class="bold"><strong>crash</strong></span>. For
        <span class="bold"><strong>InnoDB</strong></span> tables, changes from
        incomplete transactions are replayed using data from the
        <span class="bold"><strong>redo log</strong></span>. Changes that were
        <span class="bold"><strong>committed</strong></span> before the crash, but
        not yet written into the <span class="bold"><strong>data
        files</strong></span>, are reconstructed from the
        <span class="bold"><strong>doublewrite buffer</strong></span>. When the
        database is shut down normally, this type of activity is
        performed during shutdown by the
        <span class="bold"><strong>purge</strong></span> operation.
      </p><p>
        During normal operation, committed data can be stored in the
        <span class="bold"><strong>change buffer</strong></span> for a period of
        time before being written to the data files. There is always a
        tradeoff between keeping the data files up-to-date, which
        introduces performance overhead during normal operation, and
        buffering the data, which can make shutdown and crash recovery
        take longer.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_change_buffer">change buffer</a>, <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_crash">crash</a>, <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_doublewrite_buffer">doublewrite buffer</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_purge">purge</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>.</p></dd><dt><a name="glos_crud"></a><span class="glossterm">CRUD</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396753872"></a>
        Acronym for <span class="quote">“<span class="quote">create, read, update, delete</span>”</span>, a
        common sequence of operations in database applications. Often
        denotes a class of applications with relatively simple database
        usage (basic <span class="bold"><strong>DDL</strong></span>,
        <span class="bold"><strong>DML</strong></span> and
        <span class="bold"><strong>query</strong></span> statements in
        <span class="bold"><strong>SQL</strong></span>) that can be implemented
        quickly in any language.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>.</p></dd><dt><a name="glos_cursor"></a><span class="glossterm">cursor</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396746368"></a>
        An internal data structure that is used to represent the result
        set of a <span class="bold"><strong>query</strong></span>, or other
        operation that performs a search using an SQL
        <code class="literal">WHERE</code> clause. It works like an iterator in
        other high-level languages, producing each value from the result
        set as requested.
      </p><p>
        Although SQL usually handles the processing of cursors for you,
        you might delve into the inner workings when dealing with
        performance-critical code.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_query">query</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">D</h3>
<dl><dt><a name="glos_data_definition_language"></a><span class="glossterm">data definition language</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_ddl">DDL</a>.</p></dd><dt><a name="glos_data_dictionary"></a><span class="glossterm">data dictionary</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396739520"></a>
        Metadata that keeps track of database objects such as
        <span class="bold"><strong>tables</strong></span>,
        <span class="bold"><strong>indexes</strong></span>, and table
        <span class="bold"><strong>columns</strong></span>. For the MySQL data
        dictionary, introduced in MySQL 8.0, metadata is physically
        located in <code class="literal">InnoDB</code>
        <span class="bold"><strong>file-per-table</strong></span> tablespace files
        in the <code class="literal">mysql</code> database directory. For the
        <code class="literal">InnoDB</code> data dictionary, metadata is
        physically located in the <code class="literal">InnoDB</code>
        <span class="bold"><strong>system tablespace</strong></span>.
      </p><p>
        Because the <span class="bold"><strong>MySQL Enterprise
        Backup</strong></span> product always backs up the
        <code class="literal">InnoDB</code> system tablespace, all backups include
        the contents of the <code class="literal">InnoDB</code> data dictionary.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_column">column</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_frm_file">.frm file</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_data_directory"></a><span class="glossterm">data directory</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396724400"></a>
        The directory under which each MySQL
        <span class="bold"><strong>instance</strong></span> keeps the
        <span class="bold"><strong>data files</strong></span> for
        <code class="literal">InnoDB</code> and the directories representing
        individual databases. Controlled by the
        <a class="link" href="server-administration.html#sysvar_datadir"><code class="literal">datadir</code></a> configuration option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_instance">instance</a>.</p></dd><dt><a name="glos_data_files"></a><span class="glossterm">data files</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396717776"></a>
        The files that physically contain
        <span class="bold"><strong>table</strong></span> and
        <span class="bold"><strong>index</strong></span> data.
      </p><p>
        The <code class="literal">InnoDB</code> <span class="bold"><strong>system
        tablespace</strong></span>, which holds the <code class="literal">InnoDB</code>
        <span class="bold"><strong>data dictionary</strong></span> and is capable
        of holding data for multiple <code class="literal">InnoDB</code> tables,
        is represented by one or more <code class="filename">.ibdata</code> data
        files.
      </p><p>
        File-per-table tablespaces, which hold data for a single
        <code class="literal">InnoDB</code> table, are represented by a
        <code class="filename">.ibd</code> data file.
      </p><p>
        General tablespaces (introduced in MySQL 5.7.6), which can hold
        data for multiple <code class="literal">InnoDB</code> tables, are also
        represented by a <code class="literal">.ibd</code> data file.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_data_dictionary">data dictionary</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_general_tablespace">general tablespace</a>, <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_ibdata_file">ibdata file</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>.</p></dd><dt><a name="glos_data_manipulation_language"></a><span class="glossterm">data manipulation language</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_dml">DML</a>.</p></dd><dt><a name="glos_data_warehouse"></a><span class="glossterm">data warehouse</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396699552"></a>
        A database system or application that primarily runs large
        <span class="bold"><strong>queries</strong></span>. The read-only or
        read-mostly data might be organized in
        <span class="bold"><strong>denormalized</strong></span> form for query
        efficiency. Can benefit from the optimizations for
        <span class="bold"><strong>read-only transactions</strong></span> in MySQL
        5.6 and higher. Contrast with
        <span class="bold"><strong>OLTP</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_denormalized">denormalized</a>, <a class="glossseealso" href="glossary.html#glos_oltp">OLTP</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>, <a class="glossseealso" href="glossary.html#glos_read_only_transaction">read-only transaction</a>.</p></dd><dt><a name="glos_database"></a><span class="glossterm">database</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396692176"></a>
        Within the MySQL <span class="bold"><strong>data
        directory</strong></span>, each database is represented by a separate
        directory. The InnoDB <span class="bold"><strong>system
        tablespace</strong></span>, which can hold table data from multiple
        databases within a MySQL
        <span class="bold"><strong>instance</strong></span>, is kept in
        <span class="bold"><strong>data files</strong></span> that reside outside
        of individual database directories. When
        <span class="bold"><strong>file-per-table</strong></span> mode is enabled,
        the <span class="bold"><strong>.ibd files</strong></span> representing
        individual InnoDB tables are stored inside the database
        directories unless created elsewhere using the <code class="literal">DATA
        DIRECTORY</code> clause. General tablespaces, introduced in
        MySQL 5.7.6, also hold table data in <span class="bold"><strong>.ibd
        files</strong></span>. Unlike file-per-table
        <span class="bold"><strong>.ibd files</strong></span>, general tablespace
        <span class="bold"><strong>.ibd files</strong></span> can hold table data
        from multiple databases within a MySQL
        <span class="bold"><strong>instance</strong></span>, and can be assigned
        to directories relative to or independent of the MySQL data
        directory.
      </p><p>
        For long-time MySQL users, a database is a familiar notion.
        Users coming from an Oracle Database background will find that
        the MySQL meaning of a database is closer to what Oracle
        Database calls a <span class="bold"><strong>schema</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_instance">instance</a>, <a class="glossseealso" href="glossary.html#glos_schema">schema</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>.</p></dd><dt><a name="glos_dcl"></a><span class="glossterm">DCL</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396676976"></a>
        Data control language, a set of
        <span class="bold"><strong>SQL</strong></span> statements for managing
        privileges. In MySQL, consists of the
        <a class="link" href="sql-syntax.html#grant" title="13.7.1.6 GRANT Syntax"><code class="literal">GRANT</code></a> and
        <a class="link" href="sql-syntax.html#revoke" title="13.7.1.8 REVOKE Syntax"><code class="literal">REVOKE</code></a> statements. Contrast with
        <span class="bold"><strong>DDL</strong></span> and
        <span class="bold"><strong>DML</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>.</p></dd><dt><a name="glos_ddl"></a><span class="glossterm">DDL</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396668848"></a>
        Data definition language, a set of
        <span class="bold"><strong>SQL</strong></span> statements for manipulating
        the database itself rather than individual table rows. Includes
        all forms of the <code class="literal">CREATE</code>,
        <code class="literal">ALTER</code>, and <code class="literal">DROP</code>
        statements. Also includes the <code class="literal">TRUNCATE</code>
        statement, because it works differently than a <code class="literal">DELETE
        FROM <em class="replaceable"><code>table_name</code></em></code> statement,
        even though the ultimate effect is similar.
      </p><p>
        DDL statements automatically
        <span class="bold"><strong>commit</strong></span> the current
        <span class="bold"><strong>transaction</strong></span>; they cannot be
        <span class="bold"><strong>rolled back</strong></span>.
      </p><p>
        The <code class="literal">InnoDB</code>
        <a class="link" href="glossary.html#glos_online_ddl" title="online DDL">online DDL</a> feature
        enhances performance for <a class="link" href="sql-syntax.html#create-index" title="13.1.14 CREATE INDEX Syntax"><code class="literal">CREATE
        INDEX</code></a>, <a class="link" href="sql-syntax.html#drop-index" title="13.1.25 DROP INDEX Syntax"><code class="literal">DROP INDEX</code></a>, and
        many types of <a class="link" href="sql-syntax.html#alter-table" title="13.1.8 ALTER TABLE Syntax"><code class="literal">ALTER TABLE</code></a>
        operations. See <a class="xref" href="innodb-storage-engine.html#innodb-online-ddl" title="15.12 InnoDB and Online DDL">Section 15.12, “InnoDB and Online DDL”</a> for more
        information. Also, the <code class="literal">InnoDB</code>
        <a class="link" href="glossary.html#glos_file_per_table" title="file-per-table">file-per-table</a>
        setting can affect the behavior of <a class="link" href="sql-syntax.html#drop-table" title="13.1.29 DROP TABLE Syntax"><code class="literal">DROP
        TABLE</code></a> and <a class="link" href="sql-syntax.html#truncate-table" title="13.1.34 TRUNCATE TABLE Syntax"><code class="literal">TRUNCATE
        TABLE</code></a> operations.
      </p><p>
        Contrast with <span class="bold"><strong>DML</strong></span> and
        <span class="bold"><strong>DCL</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_dcl">DCL</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_deadlock"></a><span class="glossterm">deadlock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396643488"></a>
        A situation where different
        <span class="bold"><strong>transactions</strong></span> are unable to
        proceed, because each holds a
        <span class="bold"><strong>lock</strong></span> that the other needs.
        Because both transactions are waiting for a resource to become
        available, neither will ever release the locks it holds.
      </p><p>
        A deadlock can occur when the transactions lock rows in multiple
        tables (through statements such as <code class="literal">UPDATE</code> or
        <code class="literal">SELECT ... FOR UPDATE</code>), but in the opposite
        order. A deadlock can also occur when such statements lock
        ranges of index records and
        <span class="bold"><strong>gaps</strong></span>, with each transaction
        acquiring some locks but not others due to a timing issue.
      </p><p>
        For background information on how deadlocks are automatically
        detected and handled, see
        <a class="xref" href="innodb-storage-engine.html#innodb-deadlock-detection" title="15.5.5.2 Deadlock Detection and Rollback">Section 15.5.5.2, “Deadlock Detection and Rollback”</a>. For tips on
        avoiding and recovering from deadlock conditions, see
        <a class="xref" href="innodb-storage-engine.html#innodb-deadlocks-handling" title="15.5.5.3 How to Minimize and Handle Deadlocks">Section 15.5.5.3, “How to Minimize and Handle Deadlocks”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_gap">gap</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_deadlock_detection"></a><span class="glossterm">deadlock detection</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396633248"></a>
        A mechanism that automatically detects when a
        <span class="bold"><strong>deadlock</strong></span> occurs, and
        automatically <span class="bold"><strong>rolls back</strong></span> one of
        the <span class="bold"><strong>transactions</strong></span> involved (the
        <span class="bold"><strong>victim</strong></span>). Deadlock detection can
        be disabled using the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_deadlock_detect"><code class="literal">innodb_deadlock_detect</code></a>
        configuration option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_deadlock">deadlock</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>, <a class="glossseealso" href="glossary.html#glos_victim">victim</a>.</p></dd><dt><a name="glos_delete"></a><span class="glossterm">delete</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396624688"></a>
        When <code class="literal">InnoDB</code> processes a
        <code class="literal">DELETE</code> statement, the rows are immediately
        marked for deletion and no longer are returned by queries. The
        storage is reclaimed sometime later, during the periodic garbage
        collection known as the <span class="bold"><strong>purge</strong></span>
        operation. For removing large quantities of data, related
        operations with their own performance characteristics are
        <span class="bold"><strong>TRUNCATE</strong></span> and
        <span class="bold"><strong>DROP</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_drop">drop</a>, <a class="glossseealso" href="glossary.html#glos_purge">purge</a>, <a class="glossseealso" href="glossary.html#glos_truncate">truncate</a>.</p></dd><dt><a name="glos_delete_buffering"></a><span class="glossterm">delete buffering</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396617040"></a>
        The technique of storing changes to secondary index pages,
        resulting from <code class="literal">DELETE</code> operations, in the
        <span class="bold"><strong>change buffer</strong></span> rather than
        writing the changes immediately, so that the physical writes can
        be performed to minimize random I/O. (Because delete operations
        are a two-step process, this operation buffers the write that
        normally marks an index record for deletion.) It is one of the
        types of <span class="bold"><strong>change buffering</strong></span>; the
        others are <span class="bold"><strong>insert buffering</strong></span> and
        <span class="bold"><strong>purge buffering</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_change_buffer">change buffer</a>, <a class="glossseealso" href="glossary.html#glos_change_buffering">change buffering</a>, <a class="glossseealso" href="glossary.html#glos_insert_buffer">insert buffer</a>, <a class="glossseealso" href="glossary.html#glos_insert_buffering">insert buffering</a>, <a class="glossseealso" href="glossary.html#glos_purge_buffering">purge buffering</a>.</p></dd><dt><a name="glos_denormalized"></a><span class="glossterm">denormalized</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396608448"></a>
        A data storage strategy that duplicates data across different
        tables, rather than linking the tables with
        <span class="bold"><strong>foreign keys</strong></span> and
        <span class="bold"><strong>join</strong></span> queries. Typically used in
        <span class="bold"><strong>data warehouse</strong></span> applications,
        where the data is not updated after loading. In such
        applications, query performance is more important than making it
        simple to maintain consistent data during updates. Contrast with
        <span class="bold"><strong>normalized</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_data_warehouse">data warehouse</a>, <a class="glossseealso" href="glossary.html#glos_foreign_key">foreign key</a>, <a class="glossseealso" href="glossary.html#glos_join">join</a>, <a class="glossseealso" href="glossary.html#glos_normalized">normalized</a>.</p></dd><dt><a name="glos_descending_index"></a><span class="glossterm">descending index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396600944"></a>
        A type of <span class="bold"><strong>index</strong></span> where index
        storage is optimized to process <code class="literal">ORDER BY
        <em class="replaceable"><code>column</code></em> DESC</code> clauses.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_index">index</a>.</p></dd><dt><a name="glos_dictionary_object_cache"></a><span class="glossterm">dictionary object cache</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396596416"></a>
        The dictionary object cache stores previously accessed
        <span class="bold"><strong>data dictionary</strong></span> objects in
        memory to enable object reuse and minimize disk I/O. An
        <span class="bold"><strong>LRU</strong></span>-based eviction strategy is
        used to evict least recently used objects from memory. The cache
        is comprised of several partitions that store different object
        types.
      </p><p>
        For more information, see
        <a class="xref" href="data-dictionary.html#data-dictionary-object-cache" title="14.4 Dictionary Object Cache">Section 14.4, “Dictionary Object Cache”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_data_dictionary">data dictionary</a>, <a class="glossseealso" href="glossary.html#glos_lru">LRU</a>.</p></dd><dt><a name="glos_dirty_page"></a><span class="glossterm">dirty page</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396590496"></a>
        A <span class="bold"><strong>page</strong></span> in the
        <code class="literal">InnoDB</code> <span class="bold"><strong>buffer
        pool</strong></span> that has been updated in memory, where the
        changes are not yet written
        (<span class="bold"><strong>flushed</strong></span>) to the
        <span class="bold"><strong>data files</strong></span>. The opposite of a
        <span class="bold"><strong>clean page</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_clean_page">clean page</a>, <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>.</p></dd><dt><a name="glos_dirty_read"></a><span class="glossterm">dirty read</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396581408"></a>
        An operation that retrieves unreliable data, data that was
        updated by another transaction but not yet
        <span class="bold"><strong>committed</strong></span>. It is only possible
        with the <span class="bold"><strong>isolation level</strong></span> known
        as <span class="bold"><strong>read uncommitted</strong></span>.
      </p><p>
        This kind of operation does not adhere to the
        <span class="bold"><strong>ACID</strong></span> principle of database
        design. It is considered very risky, because the data could be
        <span class="bold"><strong>rolled back</strong></span>, or updated further
        before being committed; then, the transaction doing the dirty
        read would be using data that was never confirmed as accurate.
      </p><p>
        Its opposite is <span class="bold"><strong>consistent
        read</strong></span>, where <code class="literal">InnoDB</code> ensures that a
        transaction does not read information updated by another
        transaction, even if the other transaction commits in the
        meantime.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_consistent_read">consistent read</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_read_uncommitted">READ UNCOMMITTED</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>.</p></dd><dt><a name="glos_disk_based"></a><span class="glossterm">disk-based</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396569632"></a>
        A kind of database that primarily organizes data on disk storage
        (hard drives or equivalent). Data is brought back and forth
        between disk and memory to be operated upon. It is the opposite
        of an <span class="bold"><strong>in-memory database</strong></span>.
        Although <code class="literal">InnoDB</code> is disk-based, it also
        contains features such as he <span class="bold"><strong>buffer
        pool</strong></span>, multiple buffer pool instances, and the
        <span class="bold"><strong>adaptive hash index</strong></span> that allow
        certain kinds of workloads to work primarily from memory.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_adaptive_hash_index">adaptive hash index</a>, <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_in_memory_database">in-memory database</a>.</p></dd><dt><a name="glos_disk_bound"></a><span class="glossterm">disk-bound</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396562640"></a>
        A type of <span class="bold"><strong>workload</strong></span> where the
        primary <span class="bold"><strong>bottleneck</strong></span> is disk I/O.
        (Also known as <span class="bold"><strong>I/O-bound</strong></span>.)
        Typically involves frequent writes to disk, or random reads of
        more data than can fit into the <span class="bold"><strong>buffer
        pool</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_bottleneck">bottleneck</a>, <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_workload">workload</a>.</p></dd><dt><a name="glos_dml"></a><span class="glossterm">DML</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396556016"></a>
        Data manipulation language, a set of
        <span class="bold"><strong>SQL</strong></span> statements for performing
        <a class="link" href="sql-syntax.html#insert" title="13.2.6 INSERT Syntax"><code class="literal">INSERT</code></a>,
        <a class="link" href="sql-syntax.html#update" title="13.2.12 UPDATE Syntax"><code class="literal">UPDATE</code></a>, and
        <a class="link" href="sql-syntax.html#delete" title="13.2.2 DELETE Syntax"><code class="literal">DELETE</code></a> operations. The
        <a class="link" href="sql-syntax.html#select" title="13.2.10 SELECT Syntax"><code class="literal">SELECT</code></a> statement is sometimes
        considered as a DML statement, because the <code class="literal">SELECT ...
        FOR UPDATE</code> form is subject to the same considerations
        for <span class="bold"><strong>locking</strong></span> as
        <a class="link" href="sql-syntax.html#insert" title="13.2.6 INSERT Syntax"><code class="literal">INSERT</code></a>,
        <a class="link" href="sql-syntax.html#update" title="13.2.12 UPDATE Syntax"><code class="literal">UPDATE</code></a>, and
        <a class="link" href="sql-syntax.html#delete" title="13.2.2 DELETE Syntax"><code class="literal">DELETE</code></a>.
      </p><p>
        DML statements for an <code class="literal">InnoDB</code> table operate in
        the context of a <span class="bold"><strong>transaction</strong></span>,
        so their effects can be
        <span class="bold"><strong>committed</strong></span> or
        <span class="bold"><strong>rolled back</strong></span> as a single unit.
      </p><p>
        Contrast with <span class="bold"><strong>DDL</strong></span> and
        <span class="bold"><strong>DCL</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_dcl">DCL</a>, <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_document_id"></a><span class="glossterm">document id</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396534304"></a>
        In the <code class="literal">InnoDB</code> <span class="bold"><strong>full-text
        search</strong></span> feature, a special column in the table
        containing the <span class="bold"><strong>FULLTEXT index</strong></span>,
        to uniquely identify the document associated with each
        <span class="bold"><strong>ilist</strong></span> value. Its name is
        <code class="literal">FTS_DOC_ID</code> (uppercase required). The column
        itself must be of <code class="literal">BIGINT UNSIGNED NOT NULL</code>
        type, with a unique index named
        <code class="literal">FTS_DOC_ID_INDEX</code>. Preferably, you define this
        column when creating the table. If <code class="literal">InnoDB</code>
        must add the column to the table while creating a
        <code class="literal">FULLTEXT</code> index, the indexing operation is
        considerably more expensive.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_full_text_search">full-text search</a>, <a class="glossseealso" href="glossary.html#glos_fulltext_index">FULLTEXT index</a>, <a class="glossseealso" href="glossary.html#glos_ilist">ilist</a>.</p></dd><dt><a name="glos_doublewrite_buffer"></a><span class="glossterm">doublewrite buffer</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396523648"></a>
        <code class="literal">InnoDB</code> uses a file flush technique called
        doublewrite. Before writing
        <span class="bold"><strong>pages</strong></span> to the
        <span class="bold"><strong>data files</strong></span>,
        <code class="literal">InnoDB</code> first writes them to a contiguous area
        called the doublewrite buffer. Only after the write and the
        flush to the doublewrite buffer have completed, does
        <code class="literal">InnoDB</code> write the pages to their proper
        positions in the data file. If there is an operating system,
        storage subsystem, or <a class="link" href="programs.html#mysqld" title="4.3.1 mysqld — The MySQL Server"><span class="command"><strong>mysqld</strong></span></a> process crash in
        the middle of a page write, <code class="literal">InnoDB</code> can later
        find a good copy of the page from the doublewrite buffer during
        <span class="bold"><strong>crash recovery</strong></span>.
      </p><p>
        Although data is always written twice, the doublewrite buffer
        does not require twice as much I/O overhead or twice as many I/O
        operations. Data is written to the buffer itself as a large
        sequential chunk, with a single <code class="literal">fsync()</code> call
        to the operating system.
      </p><p>
        To turn off the doublewrite buffer, specify the option
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_doublewrite"><code class="literal">innodb_doublewrite=0</code></a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_crash_recovery">crash recovery</a>, <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_purge">purge</a>.</p></dd><dt><a name="glos_drop"></a><span class="glossterm">drop</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396509744"></a>
        A kind of <span class="bold"><strong>DDL</strong></span> operation that
        removes a schema object, through a statement such as
        <a class="link" href="sql-syntax.html#drop-table" title="13.1.29 DROP TABLE Syntax"><code class="literal">DROP TABLE</code></a> or
        <a class="link" href="sql-syntax.html#drop-index" title="13.1.25 DROP INDEX Syntax"><code class="literal">DROP INDEX</code></a>. It maps internally to
        an <a class="link" href="sql-syntax.html#alter-table" title="13.1.8 ALTER TABLE Syntax"><code class="literal">ALTER TABLE</code></a> statement. From an
        <code class="literal">InnoDB</code> perspective, the performance
        considerations of such operations involve the time that the
        <span class="bold"><strong>data dictionary</strong></span> is locked to
        ensure that interrelated objects are all updated, and the time
        to update memory structures such as the
        <span class="bold"><strong>buffer pool</strong></span>. For a
        <span class="bold"><strong>table</strong></span>, the drop operation has
        somewhat different characteristics than a
        <span class="bold"><strong>truncate</strong></span> operation
        (<a class="link" href="sql-syntax.html#truncate-table" title="13.1.34 TRUNCATE TABLE Syntax"><code class="literal">TRUNCATE TABLE</code></a> statement).
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_data_dictionary">data dictionary</a>, <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>, <a class="glossseealso" href="glossary.html#glos_truncate">truncate</a>.</p></dd><dt><a name="glos_dynamic_row_format"></a><span class="glossterm">dynamic row format</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396495568"></a>
        An <code class="literal">InnoDB</code> row format. Because long
        variable-length column values are stored outside of the page
        that holds the row data, it is very efficient for rows that
        include large objects. Since the large fields are typically not
        accessed to evaluate query conditions, they are not brought into
        the <span class="bold"><strong>buffer pool</strong></span> as often,
        resulting in fewer I/O operations and better utilization of
        cache memory.
      </p><p>
        As of MySQL 5.7.9, the default row format is defined by
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_default_row_format"><code class="literal">innodb_default_row_format</code></a>,
        which has a default value of <code class="literal">DYNAMIC</code>.
      </p><p>
        For additional information about <code class="literal">InnoDB</code>
        <code class="literal">DYNAMIC</code> row format, see
        <a class="xref" href="innodb-storage-engine.html#innodb-row-format-dynamic" title="15.10.3 DYNAMIC and COMPRESSED Row Formats">Section 15.10.3, “DYNAMIC and COMPRESSED Row Formats”</a>.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_file_format">file format</a>, <a class="glossseealso" href="glossary.html#glos_row_format">row format</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">E</h3>
<dl><dt><a name="glos_early_adopter"></a><span class="glossterm">early adopter</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396484592"></a>
        A stage similar to <span class="bold"><strong>beta</strong></span>, when a
        software product is typically evaluated for performance,
        functionality, and compatibility in a non-mission-critical
        setting.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_beta">beta</a>.</p></dd><dt><a name="glos_error_log"></a><span class="glossterm">error log</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396481120"></a>
        A type of <span class="bold"><strong>log</strong></span> showing
        information about MySQL startup and critical runtime errors and
        <span class="bold"><strong>crash</strong></span> information. For details,
        see <a class="xref" href="server-administration.html#error-log" title="5.4.2 The Error Log">Section 5.4.2, “The Error Log”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_crash">crash</a>, <a class="glossseealso" href="glossary.html#glos_log">log</a>.</p></dd><dt><a name="glos_eviction"></a><span class="glossterm">eviction</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396475728"></a>
        The process of removing an item from a cache or other temporary
        storage area, such as the <code class="literal">InnoDB</code>
        <span class="bold"><strong>buffer pool</strong></span>. Often, but not
        always, uses the <span class="bold"><strong>LRU</strong></span> algorithm
        to determine which item to remove. When a
        <span class="bold"><strong>dirty page</strong></span> is evicted, its
        contents are <span class="bold"><strong>flushed</strong></span> to disk,
        and any dirty <span class="bold"><strong>neighbor pages</strong></span>
        might be flushed also.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_dirty_page">dirty page</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_lru">LRU</a>, <a class="glossseealso" href="glossary.html#glos_neighbor_page">neighbor page</a>.</p></dd><dt><a name="glos_exclusive_lock"></a><span class="glossterm">exclusive lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396466672"></a>
        A kind of <span class="bold"><strong>lock</strong></span> that prevents
        any other <span class="bold"><strong>transaction</strong></span> from
        locking the same row. Depending on the transaction
        <span class="bold"><strong>isolation level</strong></span>, this kind of
        lock might block other transactions from writing to the same
        row, or might also block other transactions from reading the
        same row. The default <code class="literal">InnoDB</code> isolation level,
        <span class="bold"><strong>REPEATABLE READ</strong></span>, enables higher
        <span class="bold"><strong>concurrency</strong></span> by allowing
        transactions to read rows that have exclusive locks, a technique
        known as <span class="bold"><strong>consistent read</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_consistent_read">consistent read</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_repeatable_read">REPEATABLE READ</a>, <a class="glossseealso" href="glossary.html#glos_shared_lock">shared lock</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_extent"></a><span class="glossterm">extent</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396455680"></a>
        A group of <span class="bold"><strong>pages</strong></span> within a
        <span class="bold"><strong>tablespace</strong></span>. For the default
        <span class="bold"><strong>page size</strong></span> of 16KB, an extent
        contains 64 pages. In MySQL 5.6, the page size for an
        <code class="literal">InnoDB</code> instance can be 4KB, 8KB, or 16KB,
        controlled by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_page_size"><code class="literal">innodb_page_size</code></a> configuration
        option. For 4KB, 8KB, and 16KB pages sizes, the extent size is
        always 1MB (or 1048576 bytes).
      </p><p>
        Support for 32KB and 64KB <code class="literal">InnoDB</code> page sizes
        was added in MySQL 5.7.6. For a 32KB page size, the extent size
        is 2MB. For a 64KB page size, the extent size is 4MB.
      </p><p>
        <code class="literal">InnoDB</code> features such as
        <span class="bold"><strong>segments</strong></span>,
        <span class="bold"><strong>read-ahead</strong></span> requests and the
        <span class="bold"><strong>doublewrite buffer</strong></span> use I/O
        operations that read, write, allocate, or free data one extent
        at a time.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_doublewrite_buffer">doublewrite buffer</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_page_size">page size</a>, <a class="glossseealso" href="glossary.html#glos_read_ahead">read-ahead</a>, <a class="glossseealso" href="glossary.html#glos_segment">segment</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">F</h3>
<dl><dt><a name="glos_frm_file"></a><span class="glossterm">.frm file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396315024"></a>
        A file containing the metadata, such as the table definition, of
        a MySQL table. <code class="filename">.frm</code> files were removed in
        MySQL 8.0 but are still used in earlier MySQL releases. In MySQL
        8.0, data previously stored in <code class="filename">.frm</code> files
        is stored in <span class="bold"><strong>data dictionary</strong></span>
        tables.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_data_dictionary">data dictionary</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>.</p></dd><dt><a name="glos_fanout"></a><span class="glossterm">fanout</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396440912"></a>
        The increase or decrease in number of rows from adding a table
        during join processing. Suppose that a query of the form
        <code class="literal">SELECT ... FROM t1 INNER JOIN t2 ...</code> selects
        rows from table <code class="literal">t1</code>, then
        <code class="literal">t2</code>.
</p>
<div class="itemizedlist">
<ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
            If the join selects one row from <code class="literal">t2</code> per
            row in <code class="literal">t1</code>, the fanout for
            <code class="literal">t2</code> is 1.
          </p></li><li class="listitem"><p>
            If the join selects two rows from <code class="literal">t2</code> per
            row in <code class="literal">t1</code>, the fanout for
            <code class="literal">t2</code> is 2.
          </p></li><li class="listitem"><p>
            If the join selects one row from <code class="literal">t2</code> per
            two rows in <code class="literal">t1</code>, the fanout for
            <code class="literal">t2</code> is .5.
</p></li></ul>
</div>
</dd><dt><a name="glos_fast_index_creation"></a><span class="glossterm">Fast Index Creation</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396427280"></a>
        A capability first introduced in the InnoDB Plugin, now part of
        MySQL in 5.5 and higher, that speeds up creation of
        <code class="literal">InnoDB</code> <span class="bold"><strong>secondary
        indexes</strong></span> by avoiding the need to completely rewrite
        the associated table. The speedup applies to dropping secondary
        indexes also.
      </p><p>
        Because index maintenance can add performance overhead to many
        data transfer operations, consider doing operations such as
        <code class="literal">ALTER TABLE ... ENGINE=INNODB</code> or
        <code class="literal">INSERT INTO ... SELECT * FROM ...</code> without any
        secondary indexes in place, and creating the indexes afterward.
      </p><p>
        In MySQL 5.6, this feature becomes more general. You can read
        and write to tables while an index is being created, and many
        more kinds of <a class="link" href="sql-syntax.html#alter-table" title="13.1.8 ALTER TABLE Syntax"><code class="literal">ALTER TABLE</code></a>
        operations can be performed without copying the table, without
        blocking <span class="bold"><strong>DML</strong></span> operations, or
        both. Thus in MySQL 5.6 and higher, this set of features is
        referred to as <span class="bold"><strong>online DDL</strong></span>
        rather than Fast Index Creation.
      </p><p>
        For related information, see
        <a class="ulink" href="http://dev.mysql.com/doc/refman/5.5/en/innodb-create-index.html" target="_top">InnoDB Fast Index Creation</a>, and
        <a class="xref" href="innodb-storage-engine.html#innodb-online-ddl" title="15.12 InnoDB and Online DDL">Section 15.12, “InnoDB and Online DDL”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_online_ddl">online DDL</a>, <a class="glossseealso" href="glossary.html#glos_secondary_index">secondary index</a>.</p></dd><dt><a name="glos_fast_shutdown"></a><span class="glossterm">fast shutdown</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396414112"></a>
        The default <span class="bold"><strong>shutdown</strong></span> procedure
        for <code class="literal">InnoDB</code>, based on the configuration
        setting <a class="link" href="innodb-storage-engine.html#sysvar_innodb_fast_shutdown"><code class="literal">innodb_fast_shutdown=1</code></a>.
        To save time, certain <span class="bold"><strong>flush</strong></span>
        operations are skipped. This type of shutdown is safe during
        normal usage, because the flush operations are performed during
        the next startup, using the same mechanism as in
        <span class="bold"><strong>crash recovery</strong></span>. In cases where
        the database is being shut down for an upgrade or downgrade, do
        a <span class="bold"><strong>slow shutdown</strong></span> instead to
        ensure that all relevant changes are applied to the
        <span class="bold"><strong>data files</strong></span> during the shutdown.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_crash_recovery">crash recovery</a>, <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_shutdown">shutdown</a>, <a class="glossseealso" href="glossary.html#glos_slow_shutdown">slow shutdown</a>.</p></dd><dt><a name="glos_file_format"></a><span class="glossterm">file format</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396403488"></a>
        The file format for <code class="literal">InnoDB</code> tables.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_ibdata_file">ibdata file</a>, <a class="glossseealso" href="glossary.html#glos_row_format">row format</a>.</p></dd><dt><a name="glos_file_per_table"></a><span class="glossterm">file-per-table</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396398624"></a>
        A general name for the setting controlled by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_file_per_table"><code class="literal">innodb_file_per_table</code></a> option,
        which is an important configuration option that affects aspects
        of <code class="literal">InnoDB</code> file storage, availability of
        features, and I/O characteristics. As of MySQL 5.6.7,
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_file_per_table"><code class="literal">innodb_file_per_table</code></a> is
        enabled by default.
      </p><p>
        With the <a class="link" href="innodb-storage-engine.html#sysvar_innodb_file_per_table"><code class="literal">innodb_file_per_table</code></a>
        option enabled, you can create a table in its own
        <span class="bold"><strong>.ibd file</strong></span> rather than in the
        shared <span class="bold"><strong>ibdata files</strong></span> of the
        <span class="bold"><strong>system tablespace</strong></span>. When table
        data is stored in an individual <span class="bold"><strong>.ibd
        file</strong></span>, you have more flexibility to choose
        <span class="bold"><strong>row formats</strong></span> required for
        features such as data
        <span class="bold"><strong>compression</strong></span>. The
        <code class="literal">TRUNCATE TABLE</code> operation is also faster, and
        reclaimed space can be used by the operating system rather than
        remaining reserved for <code class="literal">InnoDB</code>.
      </p><p>
        The <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product is more flexible for tables that are in their own files.
        For example, tables can be excluded from a backup, but only if
        they are in separate files. Thus, this setting is suitable for
        tables that are backed up less frequently or on a different
        schedule.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_compressed_row_format">compressed row format</a>, <a class="glossseealso" href="glossary.html#glos_compression">compression</a>, <a class="glossseealso" href="glossary.html#glos_file_format">file format</a>, <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_ibdata_file">ibdata file</a>, <a class="glossseealso" href="glossary.html#glos_innodb_file_per_table">innodb_file_per_table</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_row_format">row format</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>.</p></dd><dt><a name="glos_fill_factor"></a><span class="glossterm">fill factor</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396379184"></a>
        In an <code class="literal">InnoDB</code>
        <span class="bold"><strong>index</strong></span>, the proportion of a
        <span class="bold"><strong>page</strong></span> that is taken up by index
        data before the page is split. The unused space when index data
        is first divided between pages allows for rows to be updated
        with longer string values without requiring expensive index
        maintenance operations. If the fill factor is too low, the index
        consumes more space than needed, causing extra I/O overhead when
        reading the index. If the fill factor is too high, any update
        that increases the length of column values can cause extra I/O
        overhead for index maintenance. See
        <a class="xref" href="innodb-storage-engine.html#innodb-physical-structure" title="15.8.2.2 The Physical Structure of an InnoDB Index">Section 15.8.2.2, “The Physical Structure of an InnoDB Index”</a> for more
        information.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>.</p></dd><dt><a name="glos_fixed_row_format"></a><span class="glossterm">fixed row format</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396372608"></a>
        This row format is used by the <code class="literal">MyISAM</code> storage
        engine, not by <code class="literal">InnoDB</code>. If you create an
        <code class="literal">InnoDB</code> table with the option
        <code class="literal">ROW_FORMAT=FIXED</code> in MySQL 5.7.6 or earlier,
        <code class="literal">InnoDB</code> uses the <span class="bold"><strong>compact
        row format</strong></span> instead, although the
        <code class="literal">FIXED</code> value might still show up in output
        such as <code class="literal">SHOW TABLE STATUS</code> reports. As of
        MySQL 5.7.7, <code class="literal">InnoDB</code> returns an error if
        <code class="literal">ROW_FORMAT=FIXED</code> is specified.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_compact_row_format">compact row format</a>, <a class="glossseealso" href="glossary.html#glos_row_format">row format</a>.</p></dd><dt><a name="glos_flush"></a><span class="glossterm">flush</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396362176"></a>
        To write changes to the database files, that had been buffered
        in a memory area or a temporary disk storage area. The
        <code class="literal">InnoDB</code> storage structures that are
        periodically flushed include the <span class="bold"><strong>redo
        log</strong></span>, the <span class="bold"><strong>undo log</strong></span>,
        and the <span class="bold"><strong>buffer pool</strong></span>.
      </p><p>
        Flushing can happen because a memory area becomes full and the
        system needs to free some space, because a
        <span class="bold"><strong>commit</strong></span> operation means the
        changes from a transaction can be finalized, or because a
        <span class="bold"><strong>slow shutdown</strong></span> operation means
        that all outstanding work should be finalized. When it is not
        critical to flush all the buffered data at once,
        <code class="literal">InnoDB</code> can use a technique called
        <span class="bold"><strong>fuzzy checkpointing</strong></span> to flush
        small batches of pages to spread out the I/O overhead.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_fuzzy_checkpointing">fuzzy checkpointing</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>, <a class="glossseealso" href="glossary.html#glos_slow_shutdown">slow shutdown</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>.</p></dd><dt><a name="glos_flush_list"></a><span class="glossterm">flush list</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396350288"></a>
        An internal <code class="literal">InnoDB</code> data structure that tracks
        <span class="bold"><strong>dirty pages</strong></span> in the
        <span class="bold"><strong>buffer pool</strong></span>: that is,
        <span class="bold"><strong>pages</strong></span> that have been changed
        and need to be written back out to disk. This data structure is
        updated frequently by <code class="literal">InnoDB</code> internal
        <span class="bold"><strong>mini-transactions</strong></span>, and so is
        protected by its own <span class="bold"><strong>mutex</strong></span> to
        allow concurrent access to the buffer pool.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_dirty_page">dirty page</a>, <a class="glossseealso" href="glossary.html#glos_lru">LRU</a>, <a class="glossseealso" href="glossary.html#glos_mini_transaction">mini-transaction</a>, <a class="glossseealso" href="glossary.html#glos_mutex">mutex</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_page_cleaner">page cleaner</a>.</p></dd><dt><a name="glos_foreign_key"></a><span class="glossterm">foreign key</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396339200"></a>
        A type of pointer relationship, between rows in separate
        <code class="literal">InnoDB</code> tables. The foreign key relationship
        is defined on one column in both the
        <span class="bold"><strong>parent table</strong></span> and the
        <span class="bold"><strong>child table</strong></span>.
      </p><p>
        In addition to enabling fast lookup of related information,
        foreign keys help to enforce <span class="bold"><strong>referential
        integrity</strong></span>, by preventing any of these pointers from
        becoming invalid as data is inserted, updated, and deleted. This
        enforcement mechanism is a type of
        <span class="bold"><strong>constraint</strong></span>. A row that points
        to another table cannot be inserted if the associated foreign
        key value does not exist in the other table. If a row is deleted
        or its foreign key value changed, and rows in another table
        point to that foreign key value, the foreign key can be set up
        to prevent the deletion, cause the corresponding column values
        in the other table to become
        <span class="bold"><strong>null</strong></span>, or automatically delete
        the corresponding rows in the other table.
      </p><p>
        One of the stages in designing a
        <span class="bold"><strong>normalized</strong></span> database is to
        identify data that is duplicated, separate that data into a new
        table, and set up a foreign key relationship so that the
        multiple tables can be queried like a single table, using a
        <span class="bold"><strong>join</strong></span> operation.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_child_table">child table</a>, <a class="glossseealso" href="glossary.html#glos_foreign_key_constraint">FOREIGN KEY constraint</a>, <a class="glossseealso" href="glossary.html#glos_join">join</a>, <a class="glossseealso" href="glossary.html#glos_normalized">normalized</a>, <a class="glossseealso" href="glossary.html#glos_null">NULL</a>, <a class="glossseealso" href="glossary.html#glos_parent_table">parent table</a>, <a class="glossseealso" href="glossary.html#glos_referential_integrity">referential integrity</a>, <a class="glossseealso" href="glossary.html#glos_relational">relational</a>.</p></dd><dt><a name="glos_foreign_key_constraint"></a><span class="glossterm">FOREIGN KEY constraint</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396325136"></a>
        The type of <span class="bold"><strong>constraint</strong></span> that
        maintains database consistency through a
        <span class="bold"><strong>foreign key</strong></span> relationship. Like
        other kinds of constraints, it can prevent data from being
        inserted or updated if data would become inconsistent; in this
        case, the inconsistency being prevented is between data in
        multiple tables. Alternatively, when a
        <span class="bold"><strong>DML</strong></span> operation is performed,
        <code class="literal">FOREIGN KEY</code> constraints can cause data in
        <span class="bold"><strong>child rows</strong></span> to be deleted,
        changed to different values, or set to
        <span class="bold"><strong>null</strong></span>, based on the <code class="literal">ON
        CASCADE</code> option specified when creating the foreign
        key.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_child_table">child table</a>, <a class="glossseealso" href="glossary.html#glos_constraint">constraint</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_foreign_key">foreign key</a>, <a class="glossseealso" href="glossary.html#glos_null">NULL</a>.</p></dd><dt><a name="glos_fts"></a><span class="glossterm">FTS</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396308640"></a>
        In most contexts, an acronym for <span class="bold"><strong>full-text
        search</strong></span>. Sometimes in performance discussions, an
        acronym for <span class="bold"><strong>full table scan</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_full_table_scan">full table scan</a>, <a class="glossseealso" href="glossary.html#glos_full_text_search">full-text search</a>.</p></dd><dt><a name="glos_full_backup"></a><span class="glossterm">full backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396304080"></a>
        A <span class="bold"><strong>backup</strong></span> that includes all the
        <span class="bold"><strong>tables</strong></span> in each MySQL
        <span class="bold"><strong>database</strong></span>, and all the databases
        in a MySQL <span class="bold"><strong>instance</strong></span>. Contrast
        with <span class="bold"><strong>partial backup</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_backup">backup</a>, <a class="glossseealso" href="glossary.html#glos_database">database</a>, <a class="glossseealso" href="glossary.html#glos_instance">instance</a>, <a class="glossseealso" href="glossary.html#glos_partial_backup">partial backup</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_full_table_scan"></a><span class="glossterm">full table scan</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396295600"></a>
        An operation that requires reading the entire contents of a
        table, rather than just selected portions using an
        <span class="bold"><strong>index</strong></span>. Typically performed
        either with small lookup tables, or in data warehousing
        situations with large tables where all available data is
        aggregated and analyzed. How frequently these operations occur,
        and the sizes of the tables relative to available memory, have
        implications for the algorithms used in query optimization and
        managing the <span class="bold"><strong>buffer pool</strong></span>.
      </p><p>
        The purpose of indexes is to allow lookups for specific values
        or ranges of values within a large table, thus avoiding full
        table scans when practical.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>.</p></dd><dt><a name="glos_full_text_search"></a><span class="glossterm">full-text search</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396290048"></a>
        The MySQL feature for finding words, phrases, Boolean
        combinations of words, and so on within table data, in a faster,
        more convenient, and more flexible way than using the SQL
        <code class="literal">LIKE</code> operator or writing your own
        application-level search algorithm. It uses the SQL function
        <a class="link" href="functions.html#function_match"><code class="literal">MATCH()</code></a> and
        <span class="bold"><strong>FULLTEXT indexes</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_fulltext_index">FULLTEXT index</a>.</p></dd><dt><a name="glos_fulltext_index"></a><span class="glossterm">FULLTEXT index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396284560"></a>
        The special kind of <span class="bold"><strong>index</strong></span> that
        holds the <span class="bold"><strong>search index</strong></span> in the
        MySQL <span class="bold"><strong>full-text search</strong></span>
        mechanism. Represents the words from values of a column,
        omitting any that are specified as
        <span class="bold"><strong>stopwords</strong></span>. Originally, only
        available for <code class="literal">MyISAM</code> tables. Starting in
        MySQL 5.6.4, it is also available for
        <span class="bold"><strong>InnoDB</strong></span> tables.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_full_text_search">full-text search</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_search_index">search index</a>, <a class="glossseealso" href="glossary.html#glos_stopword">stopword</a>.</p></dd><dt><a name="glos_fuzzy_checkpointing"></a><span class="glossterm">fuzzy checkpointing</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396275360"></a>
        A technique that <span class="bold"><strong>flushes</strong></span> small
        batches of <span class="bold"><strong>dirty pages</strong></span> from the
        <span class="bold"><strong>buffer pool</strong></span>, rather than
        flushing all dirty pages at once which would disrupt database
        processing.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_dirty_page">dirty page</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">G</h3>
<dl><dt><a name="glos_ga"></a><span class="glossterm">GA</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396269056"></a>
        <span class="quote">“<span class="quote">Generally available</span>”</span>, the stage when a software
        product leaves <span class="bold"><strong>beta</strong></span> and is
        available for sale, official support, and production use.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_beta">beta</a>.</p></dd><dt><a name="glos_gap"></a><span class="glossterm">gap</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396265360"></a>
        A place in an <code class="literal">InnoDB</code>
        <span class="bold"><strong>index</strong></span> data structure where new
        values could be inserted. When you lock a set of rows with a
        statement such as <code class="literal">SELECT ... FOR UPDATE</code>,
        <code class="literal">InnoDB</code> can create locks that apply to the
        gaps as well as the actual values in the index. For example, if
        you select all values greater than 10 for update, a gap lock
        prevents another transaction from inserting a new value that is
        greater than 10. The <span class="bold"><strong>supremum
        record</strong></span> and <span class="bold"><strong>infimum
        record</strong></span> represent the gaps containing all values
        greater than or less than all the current index values.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_gap_lock">gap lock</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_infimum_record">infimum record</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_supremum_record">supremum record</a>.</p></dd><dt><a name="glos_gap_lock"></a><span class="glossterm">gap lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396255232"></a>
        A <span class="bold"><strong>lock</strong></span> on a
        <span class="bold"><strong>gap</strong></span> between index records, or a
        lock on the gap before the first or after the last index record.
        For example, <code class="literal">SELECT c1 FROM t WHERE c1 BETWEEN 10 and
        20 FOR UPDATE;</code> prevents other transactions from
        inserting a value of 15 into the column <code class="literal">t.c1</code>,
        whether or not there was already any such value in the column,
        because the gaps between all existing values in the range are
        locked. Contrast with <span class="bold"><strong>record
        lock</strong></span> and <span class="bold"><strong>next-key
        lock</strong></span>.
      </p><p>
        Gap locks are part of the tradeoff between performance and
        <span class="bold"><strong>concurrency</strong></span>, and are used in
        some transaction <span class="bold"><strong>isolation
        levels</strong></span> and not others.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_gap">gap</a>, <a class="glossseealso" href="glossary.html#glos_infimum_record">infimum record</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_next_key_lock">next-key lock</a>, <a class="glossseealso" href="glossary.html#glos_record_lock">record lock</a>, <a class="glossseealso" href="glossary.html#glos_supremum_record">supremum record</a>.</p></dd><dt><a name="glos_general_log"></a><span class="glossterm">general log</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_general_query_log">general query log</a>.</p></dd><dt><a name="glos_general_query_log"></a><span class="glossterm">general query log</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396241744"></a>
        A type of <span class="bold"><strong>log</strong></span> used for
        diagnosis and troubleshooting of SQL statements processed by the
        MySQL server. Can be stored in a file or in a database table.
        You must enable this feature through the
        <a class="link" href="server-administration.html#sysvar_general_log"><code class="literal">general_log</code></a> configuration
        option to use it. You can disable it for a specific connection
        through the <a class="link" href="server-administration.html#sysvar_sql_log_off"><code class="literal">sql_log_off</code></a>
        configuration option.
      </p><p>
        Records a broader range of queries than the
        <span class="bold"><strong>slow query log</strong></span>. Unlike the
        <span class="bold"><strong>binary log</strong></span>, which is used for
        replication, the general query log contains
        <a class="link" href="sql-syntax.html#select" title="13.2.10 SELECT Syntax"><code class="literal">SELECT</code></a> statements and does not
        maintain strict ordering. For more information, see
        <a class="xref" href="server-administration.html#query-log" title="5.4.3 The General Query Log">Section 5.4.3, “The General Query Log”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_binary_log">binary log</a>, <a class="glossseealso" href="glossary.html#glos_log">log</a>, <a class="glossseealso" href="glossary.html#glos_slow_query_log">slow query log</a>.</p></dd><dt><a name="glos_general_tablespace"></a><span class="glossterm">general tablespace</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396230608"></a>
        A shared <code class="literal">InnoDB</code>
        <span class="bold"><strong>tablespace</strong></span> created using
        <a class="link" href="sql-syntax.html#create-tablespace" title="13.1.19 CREATE TABLESPACE Syntax"><code class="literal">CREATE TABLESPACE</code></a> syntax. General
        tablespaces can be created outside of the MySQL data directory,
        are capable of holding multiple
        <span class="bold"><strong>tables</strong></span>, and support tables of
        all row formats. General tablespaces were introduced in MySQL
        5.7.6.
      </p><p>
        Tables are added to a general tablespace using
        <a class="link" href="sql-syntax.html#create-table" title="13.1.18 CREATE TABLE Syntax"><code class="literal">CREATE TABLE
        <em class="replaceable"><code>tbl_name</code></em> ... TABLESPACE [=]
        <em class="replaceable"><code>tablespace_name</code></em></code></a> or
        <a class="link" href="sql-syntax.html#alter-table" title="13.1.8 ALTER TABLE Syntax"><code class="literal">ALTER TABLE
        <em class="replaceable"><code>tbl_name</code></em> TABLESPACE [=]
        <em class="replaceable"><code>tablespace_name</code></em></code></a> syntax.
      </p><p>
        Contrast with <span class="bold"><strong>system tablespace</strong></span>
        and <span class="bold"><strong>file-per-table</strong></span> tablespace.
      </p><p>
        For more information, see <a class="xref" href="innodb-storage-engine.html#general-tablespaces" title="15.7.10 InnoDB General Tablespaces">Section 15.7.10, “InnoDB General Tablespaces”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>.</p></dd><dt><a name="glos_generated_column"></a><span class="glossterm">generated column</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396215568"></a>
        A column whose values are computed from an expression included
        in the column definition. A generated column can be
        <span class="bold"><strong>virtual</strong></span> or
        <span class="bold"><strong>stored</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_base_column">base column</a>, <a class="glossseealso" href="glossary.html#glos_stored_generated_column">stored generated column</a>, <a class="glossseealso" href="glossary.html#glos_virtual_generated_column">virtual generated column</a>.</p></dd><dt><a name="glos_generated_stored_column"></a><span class="glossterm">generated stored column</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_stored_generated_column">stored generated column</a>.</p></dd><dt><a name="glos_generated_virtual_column"></a><span class="glossterm">generated virtual column</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_virtual_generated_column">virtual generated column</a>.</p></dd><dt><a name="glos_global_transaction"></a><span class="glossterm">global transaction</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396207312"></a>
        A type of <span class="bold"><strong>transaction</strong></span> involved
        in <span class="bold"><strong>XA</strong></span> operations. It consists
        of several actions that are transactional in themselves, but
        that all must either complete successfully as a group, or all be
        rolled back as a group. In essence, this extends
        <span class="bold"><strong>ACID</strong></span> properties <span class="quote">“<span class="quote">up a
        level</span>”</span> so that multiple ACID transactions can be executed
        in concert as components of a global operation that also has
        ACID properties.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>, <a class="glossseealso" href="glossary.html#glos_xa">XA</a>.</p></dd><dt><a name="glos_group_commit"></a><span class="glossterm">group commit</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396200816"></a>
        An <code class="literal">InnoDB</code> optimization that performs some
        low-level I/O operations (log write) once for a set of
        <span class="bold"><strong>commit</strong></span> operations, rather than
        flushing and syncing separately for each commit.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_binary_log">binary log</a>, <a class="glossseealso" href="glossary.html#glos_commit">commit</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">H</h3>
<dl><dt><a name="glos_hash_index"></a><span class="glossterm">hash index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396195584"></a>
        A type of <span class="bold"><strong>index</strong></span> intended for
        queries that use equality operators, rather than range operators
        such as greater-than or <code class="literal">BETWEEN</code>. It is
        available for <a class="link" href="storage-engines.html#memory-storage-engine" title="16.3 The MEMORY Storage Engine"><code class="literal">MEMORY</code></a> tables.
        Although hash indexes are the default for
        <a class="link" href="storage-engines.html#memory-storage-engine" title="16.3 The MEMORY Storage Engine"><code class="literal">MEMORY</code></a> tables for historic reasons,
        that storage engine also supports
        <span class="bold"><strong>B-tree</strong></span> indexes, which are often
        a better choice for general-purpose queries.
      </p><p>
        MySQL includes a variant of this index type, the
        <span class="bold"><strong>adaptive hash index</strong></span>, that is
        constructed automatically for
        <a class="link" href="innodb-storage-engine.html" title="Chapter 15 The InnoDB Storage Engine"><code class="literal">InnoDB</code></a> tables if needed based on
        runtime conditions.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_adaptive_hash_index">adaptive hash index</a>, <a class="glossseealso" href="glossary.html#glos_b_tree">B-tree</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>.</p></dd><dt><a name="glos_hdd"></a><span class="glossterm">HDD</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396184064"></a>
        Acronym for <span class="quote">“<span class="quote">hard disk drive</span>”</span>. Refers to storage
        media using spinning platters, usually when comparing and
        contrasting with <span class="bold"><strong>SSD</strong></span>. Its
        performance characteristics can influence the throughput of a
        <span class="bold"><strong>disk-based</strong></span> workload.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_disk_based">disk-based</a>, <a class="glossseealso" href="glossary.html#glos_ssd">SSD</a>.</p></dd><dt><a name="glos_heartbeat"></a><span class="glossterm">heartbeat</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396178896"></a>
        A periodic message that is sent to indicate that a system is
        functioning properly. In a
        <span class="bold"><strong>replication</strong></span> context, if the
        <span class="bold"><strong>master</strong></span> stops sending such
        messages, one of the <span class="bold"><strong>slaves</strong></span> can
        take its place. Similar techniques can be used between the
        servers in a cluster environment, to confirm that all of them
        are operating properly.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_master_server">master server</a>, <a class="glossseealso" href="glossary.html#glos_replication">replication</a>.</p></dd><dt><a name="glos_high_water_mark"></a><span class="glossterm">high-water mark</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396173280"></a>
        A value representing an upper limit, either a hard limit that
        should not be exceeded at runtime, or a record of the maximum
        value that was actually reached. Contrast with
        <span class="bold"><strong>low-water mark</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_low_water_mark">low-water mark</a>.</p></dd><dt><a name="glos_history_list"></a><span class="glossterm">history list</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396169664"></a>
        A list of <span class="bold"><strong>transactions</strong></span> with
        delete-marked records scheduled to be processed by the
        <code class="literal">InnoDB</code> <span class="bold"><strong>purge</strong></span>
        operation. Recorded in the <span class="bold"><strong>undo
        log</strong></span>. The length of the history list is reported by
        the command <code class="literal">SHOW ENGINE INNODB STATUS</code>. If the
        history list grows longer than the value of the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_max_purge_lag"><code class="literal">innodb_max_purge_lag</code></a>
        configuration option, each <span class="bold"><strong>DML</strong></span>
        operation is delayed slightly to allow the purge operation to
        finish <span class="bold"><strong>flushing</strong></span> the deleted
        records.
      </p><p>
        Also known as <span class="bold"><strong>purge lag</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_purge">purge</a>, <a class="glossseealso" href="glossary.html#glos_purge_lag">purge lag</a>, <a class="glossseealso" href="glossary.html#glos_rollback_segment">rollback segment</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>.</p></dd><dt><a name="glos_hole_punching"></a><span class="glossterm">hole punching</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396156224"></a>
        Releasing empty blocks from a page. The
        <code class="literal">InnoDB</code> <span class="bold"><strong>transparent page
        compression</strong></span> feature relies on hole punching support.
        For more information, see
        <a class="xref" href="innodb-storage-engine.html#innodb-page-compression" title="15.9.2 InnoDB Page Compression">Section 15.9.2, “InnoDB Page Compression”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_sparse_file">sparse file</a>, <a class="glossseealso" href="glossary.html#glos_transparent_page_compression">transparent page compression</a>.</p></dd><dt><a name="glos_hot"></a><span class="glossterm">hot</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396150784"></a>
        A condition where a row, table, or internal data structure is
        accessed so frequently, requiring some form of locking or mutual
        exclusion, that it results in a performance or scalability
        issue.
      </p><p>
        Although <span class="quote">“<span class="quote">hot</span>”</span> typically indicates an undesirable
        condition, a <span class="bold"><strong>hot backup</strong></span> is the
        preferred type of backup.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>.</p></dd><dt><a name="glos_hot_backup"></a><span class="glossterm">hot backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396146512"></a>
        A backup taken while the database is running and applications
        are reading and writing to it. The backup involves more than
        simply copying data files: it must include any data that was
        inserted or updated while the backup was in process; it must
        exclude any data that was deleted while the backup was in
        process; and it must ignore any changes that were not committed.
      </p><p>
        The Oracle product that performs hot backups, of
        <code class="literal">InnoDB</code> tables especially but also tables from
        <code class="literal">MyISAM</code> and other storage engines, is known as
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span>.
      </p><p>
        The hot backup process consists of two stages. The initial
        copying of the data files produces a <span class="bold"><strong>raw
        backup</strong></span>. The <span class="bold"><strong>apply</strong></span>
        step incorporates any changes to the database that happened
        while the backup was running. Applying the changes produces a
        <span class="bold"><strong>prepared</strong></span> backup; these files
        are ready to be restored whenever necessary.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_apply">apply</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_prepared_backup">prepared backup</a>, <a class="glossseealso" href="glossary.html#glos_raw_backup">raw backup</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">I</h3>
<dl><dt><a name="glos_ibd_file"></a><span class="glossterm">.ibd file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396102544"></a>
        The data file for
        <span class="bold"><strong>file-per-table</strong></span> tablespaces and
        general tablespaces. File-per-table tablespace
        <code class="literal">.idb</code> files contain a single table and
        associated index data. <span class="bold"><strong>General
        tablespace</strong></span> <code class="literal">.idb</code> files may contain
        table and index data for multiple tables.
      </p><p>
        The <code class="literal">.ibd</code> file extension does not apply to the
        <span class="bold"><strong>system tablespace</strong></span>, which
        consists of one or more <span class="bold"><strong>ibdata
        files</strong></span>.
      </p><p>
        If a file-per-table tablespace or general tablespace is created
        with the <code class="literal">DATA DIRECTORY =</code> clause, the
        <code class="literal">.ibd</code> file is located at the specified path,
        outside the normal data directory.
      </p><p>
        When a <code class="literal">.ibd</code> file is included in a compressed
        backup by the <span class="bold"><strong>MySQL Enterprise
        Backup</strong></span> product, the compressed equivalent is a
        <code class="literal">.ibz</code> file.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_database">database</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_general_tablespace">general tablespace</a>, <a class="glossseealso" href="glossary.html#glos_ibdata_file">ibdata file</a>, <a class="glossseealso" href="glossary.html#glos_ibz_file">.ibz file</a>, <a class="glossseealso" href="glossary.html#glos_innodb_file_per_table">innodb_file_per_table</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>.</p></dd><dt><a name="glos_ibz_file"></a><span class="glossterm">.ibz file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396056304"></a>
        When the <span class="bold"><strong>MySQL Enterprise
        Backup</strong></span> product performs a
        <span class="bold"><strong>compressed backup</strong></span>, it
        transforms each <span class="bold"><strong>tablespace</strong></span> file
        that is created using the
        <span class="bold"><strong>file-per-table</strong></span> setting from a
        <code class="literal">.ibd</code> extension to a <code class="literal">.ibz</code>
        extension.
      </p><p>
        The compression applied during backup is distinct from the
        <span class="bold"><strong>compressed row format</strong></span> that
        keeps table data compressed during normal operation. A
        compressed backup operation skips the compression step for a
        tablespace that is already in compressed row format, as
        compressing a second time would slow down the backup but produce
        little or no space savings.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_compressed_backup">compressed backup</a>, <a class="glossseealso" href="glossary.html#glos_compressed_row_format">compressed row format</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>.</p></dd><dt><a name="glos_io_bound"></a><span class="glossterm">I/O-bound</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_disk_bound">disk-bound</a>.</p></dd><dt><a name="glos_ib_file_set"></a><span class="glossterm">ib-file set</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396134544"></a>
        The set of files managed by <code class="literal">InnoDB</code> within a
        MySQL database: the <span class="bold"><strong>system
        tablespace</strong></span>,
        <span class="bold"><strong>file-per-table</strong></span> tablespace
        files, and <span class="bold"><strong>redo log</strong></span> files.
        Depending on MySQL version and <code class="literal">InnoDB</code>
        configuration, may also include <span class="bold"><strong>general
        tablespace</strong></span>, <span class="bold"><strong>temporary
        tablespace</strong></span>, and <span class="bold"><strong>undo
        tablespace</strong></span> files. This term is sometimes used in
        detailed discussions of <code class="literal">InnoDB</code> file
        structures and formats to refer to the set of files managed by
        <code class="literal">InnoDB</code> within a MySQL database.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_database">database</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_general_tablespace">general tablespace</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_temporary_tablespace">temporary tablespace</a>, <a class="glossseealso" href="glossary.html#glos_undo_tablespace">undo tablespace</a>.</p></dd><dt><a name="glos_ibbackup_logfile"></a><span class="glossterm">ibbackup_logfile</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396112688"></a>
        A supplemental backup file created by the
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span> product
        during a <span class="bold"><strong>hot backup</strong></span> operation.
        It contains information about any data changes that occurred
        while the backup was running. The initial backup files,
        including <code class="literal">ibbackup_logfile</code>, are known as a
        <span class="bold"><strong>raw backup</strong></span>, because the changes
        that occurred during the backup operation are not yet
        incorporated. After you perform the
        <span class="bold"><strong>apply</strong></span> step to the raw backup
        files, the resulting files do include those final data changes,
        and are known as a <span class="bold"><strong>prepared
        backup</strong></span>. At this stage, the
        <code class="literal">ibbackup_logfile</code> file is no longer necessary.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_apply">apply</a>, <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_prepared_backup">prepared backup</a>, <a class="glossseealso" href="glossary.html#glos_raw_backup">raw backup</a>.</p></dd><dt><a name="glos_ibdata_file"></a><span class="glossterm">ibdata file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396085536"></a>
        A set of files with names such as <code class="literal">ibdata1</code>,
        <code class="literal">ibdata2</code>, and so on, that make up the InnoDB
        <span class="bold"><strong>system tablespace</strong></span>. These files
        contain metadata about <code class="literal">InnoDB</code> tables, (the
        <code class="literal">InnoDB</code> <span class="bold"><strong>data
        dictionary</strong></span>), and the storage areas for one or more
        <span class="bold"><strong>undo logs</strong></span>, the
        <span class="bold"><strong>change buffer</strong></span>, and the
        <span class="bold"><strong>doublewrite buffer</strong></span>. They also
        can contain some or all of the table data also (depending on
        whether the <span class="bold"><strong>file-per-table</strong></span> mode
        is in effect when each table is created). When the
        <span class="bold"><strong>innodb_file_per_table</strong></span> option is
        enabled, data and indexes for newly created tables are stored in
        separate <span class="bold"><strong>.ibd files</strong></span> rather than
        in the system tablespace.
      </p><p>
        The growth of the <code class="literal">ibdata</code> files is influenced
        by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoextend_increment"><code class="literal">innodb_autoextend_increment</code></a>
        configuration option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_change_buffer">change buffer</a>, <a class="glossseealso" href="glossary.html#glos_data_dictionary">data dictionary</a>, <a class="glossseealso" href="glossary.html#glos_doublewrite_buffer">doublewrite buffer</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_innodb_file_per_table">innodb_file_per_table</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>.</p></dd><dt><a name="glos_ibtmp_file"></a><span class="glossterm">ibtmp file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396067872"></a>
        The <code class="literal">InnoDB</code> <span class="bold"><strong>temporary
        tablespace</strong></span> <span class="bold"><strong>data file</strong></span>
        for non-compressed <code class="literal">InnoDB</code>
        <span class="bold"><strong>temporary tables</strong></span> and related
        objects. The configuration file option,
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_temp_data_file_path"><code class="literal">innodb_temp_data_file_path</code></a>,
        allows users to define a relative path for the temporary
        tablespace data file. If
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_temp_data_file_path"><code class="literal">innodb_temp_data_file_path</code></a> is
        not specified, the default behavior is to create a single
        auto-extending 12MB data file named <code class="filename">ibtmp1</code>
        in the data directory, alongside <code class="filename">ibdata1</code>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_temporary_table">temporary table</a>, <a class="glossseealso" href="glossary.html#glos_temporary_tablespace">temporary tablespace</a>.</p></dd><dt><a name="glos_ib_logfile"></a><span class="glossterm">ib_logfile</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396121408"></a>
        A set of files, typically named <code class="literal">ib_logfile0</code>
        and <code class="literal">ib_logfile1</code>, that form the
        <span class="bold"><strong>redo log</strong></span>. Also sometimes
        referred to as the <span class="bold"><strong>log group</strong></span>.
        These files record statements that attempt to change data in
        <code class="literal">InnoDB</code> tables. These statements are replayed
        automatically to correct data written by incomplete
        transactions, on startup following a crash.
      </p><p>
        This data cannot be used for manual recovery; for that type of
        operation, use the <span class="bold"><strong>binary log</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_binary_log">binary log</a>, <a class="glossseealso" href="glossary.html#glos_log_group">log group</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>.</p></dd><dt><a name="glos_ilist"></a><span class="glossterm">ilist</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396044928"></a>
        Within an <code class="literal">InnoDB</code>
        <span class="bold"><strong>FULLTEXT index</strong></span>, the data
        structure consisting of a document ID and positional information
        for a token (that is, a particular word).
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_fulltext_index">FULLTEXT index</a>.</p></dd><dt><a name="glos_implicit_row_lock"></a><span class="glossterm">implicit row lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396040752"></a>
        A row lock that <code class="literal">InnoDB</code> acquires to ensure
        consistency, without you specifically requesting it.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_row_lock">row lock</a>.</p></dd><dt><a name="glos_in_memory_database"></a><span class="glossterm">in-memory database</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396037360"></a>
        A type of database system that maintains data in memory, to
        avoid overhead due to disk I/O and translation between disk
        blocks and memory areas. Some in-memory databases sacrifice
        durability (the <span class="quote">“<span class="quote">D</span>”</span> in the
        <span class="bold"><strong>ACID</strong></span> design philosophy) and are
        vulnerable to hardware, power, and other types of failures,
        making them more suitable for read-only operations. Other
        in-memory databases do use durability mechanisms such as logging
        changes to disk or using non-volatile memory.
      </p><p>
        MySQL features that address the same kinds of memory-intensive
        processing include the <code class="literal">InnoDB</code>
        <span class="bold"><strong>buffer pool</strong></span>,
        <span class="bold"><strong>adaptive hash index</strong></span>, and
        <span class="bold"><strong>read-only transaction</strong></span>
        optimization, the <a class="link" href="storage-engines.html#memory-storage-engine" title="16.3 The MEMORY Storage Engine"><code class="literal">MEMORY</code></a> storage
        engine, the <code class="literal">MyISAM</code> key cache, and the MySQL
        query cache.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_adaptive_hash_index">adaptive hash index</a>, <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_disk_based">disk-based</a>, <a class="glossseealso" href="glossary.html#glos_read_only_transaction">read-only transaction</a>.</p></dd><dt><a name="glos_incremental_backup"></a><span class="glossterm">incremental backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396025696"></a>
        A type of <span class="bold"><strong>hot backup</strong></span>, performed
        by the <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product, that only saves data changed since some point in time.
        Having a full backup and a succession of incremental backups
        lets you reconstruct backup data over a long period, without the
        storage overhead of keeping several full backups on hand. You
        can restore the full backup and then apply each of the
        incremental backups in succession, or you can keep the full
        backup up-to-date by applying each incremental backup to it,
        then perform a single restore operation.
      </p><p>
        The granularity of changed data is at the
        <span class="bold"><strong>page</strong></span> level. A page might
        actually cover more than one row. Each changed page is included
        in the backup.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>.</p></dd><dt><a name="glos_index"></a><span class="glossterm">index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899396018816"></a>
        A data structure that provides a fast lookup capability for
        <span class="bold"><strong>rows</strong></span> of a
        <span class="bold"><strong>table</strong></span>, typically by forming a
        tree structure (<span class="bold"><strong>B-tree)</strong></span>
        representing all the values of a particular
        <span class="bold"><strong>column</strong></span> or set of columns.
      </p><p>
        <code class="literal">InnoDB</code> tables always have a
        <span class="bold"><strong>clustered index</strong></span> representing
        the <span class="bold"><strong>primary key</strong></span>. They can also
        have one or more <span class="bold"><strong>secondary
        indexes</strong></span> defined on one or more columns. Depending on
        their structure, secondary indexes can be classified as
        <span class="bold"><strong>partial</strong></span>,
        <span class="bold"><strong>column</strong></span>, or
        <span class="bold"><strong>composite</strong></span> indexes.
      </p><p>
        Indexes are a crucial aspect of
        <span class="bold"><strong>query</strong></span> performance. Database
        architects design tables, queries, and indexes to allow fast
        lookups for data needed by applications. The ideal database
        design uses a <span class="bold"><strong>covering index</strong></span>
        where practical; the query results are computed entirely from
        the index, without reading the actual table data. Each
        <span class="bold"><strong>foreign key</strong></span> constraint also
        requires an index, to efficiently check whether values exist in
        both the <span class="bold"><strong>parent</strong></span> and
        <span class="bold"><strong>child</strong></span> tables.
      </p><p>
        Although a B-tree index is the most common, a different kind of
        data structure is used for <span class="bold"><strong>hash
        indexes</strong></span>, as in the <code class="literal">MEMORY</code> storage
        engine and the <code class="literal">InnoDB</code>
        <span class="bold"><strong>adaptive hash index</strong></span>.
        <span class="bold"><strong>R-tree</strong></span> indexes are used for
        spatial indexing of multi-dimensional information.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_adaptive_hash_index">adaptive hash index</a>, <a class="glossseealso" href="glossary.html#glos_b_tree">B-tree</a>, <a class="glossseealso" href="glossary.html#glos_child_table">child table</a>, <a class="glossseealso" href="glossary.html#glos_clustered_index">clustered index</a>, <a class="glossseealso" href="glossary.html#glos_column_index">column index</a>, <a class="glossseealso" href="glossary.html#glos_composite_index">composite index</a>, <a class="glossseealso" href="glossary.html#glos_covering_index">covering index</a>, <a class="glossseealso" href="glossary.html#glos_foreign_key">foreign key</a>, <a class="glossseealso" href="glossary.html#glos_hash_index">hash index</a>, <a class="glossseealso" href="glossary.html#glos_parent_table">parent table</a>, <a class="glossseealso" href="glossary.html#glos_partial_index">partial index</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>, <a class="glossseealso" href="glossary.html#glos_r_tree">R-tree</a>, <a class="glossseealso" href="glossary.html#glos_row">row</a>, <a class="glossseealso" href="glossary.html#glos_secondary_index">secondary index</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_index_cache"></a><span class="glossterm">index cache</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395990544"></a>
        A memory area that holds the token data for
        <code class="literal">InnoDB</code> <span class="bold"><strong>full-text
        search</strong></span>. It buffers the data to minimize disk I/O when
        data is inserted or updated in columns that are part of a
        <span class="bold"><strong>FULLTEXT index</strong></span>. The token data
        is written to disk when the index cache becomes full. Each
        <code class="literal">InnoDB</code> <code class="literal">FULLTEXT</code> index has
        its own separate index cache, whose size is controlled by the
        configuration option
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_ft_cache_size"><code class="literal">innodb_ft_cache_size</code></a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_full_text_search">full-text search</a>, <a class="glossseealso" href="glossary.html#glos_fulltext_index">FULLTEXT index</a>.</p></dd><dt><a name="glos_index_condition_pushdown"></a><span class="glossterm">index condition pushdown</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395982160"></a>
        Index condition pushdown (ICP) is an optimization that pushes
        part of a <code class="literal">WHERE</code> condition down to the storage
        engine if parts of the condition can be evaluated using fields
        from the <span class="bold"><strong>index</strong></span>. ICP can reduce
        the number of times the <span class="bold"><strong>storage
        engine</strong></span> must access the base table and the number of
        times the MySQL server must access the storage engine. For more
        information, see
        <a class="xref" href="optimization.html#index-condition-pushdown-optimization" title="8.2.1.5 Index Condition Pushdown Optimization">Section 8.2.1.5, “Index Condition Pushdown Optimization”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_storage_engine">storage engine</a>.</p></dd><dt><a name="glos_index_hint"></a><span class="glossterm">index hint</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395975936"></a>
        Extended SQL syntax for overriding the
        <span class="bold"><strong>indexes</strong></span> recommended by the
        optimizer. For example, the <code class="literal">FORCE INDEX</code>,
        <code class="literal">USE INDEX</code>, and <code class="literal">IGNORE
        INDEX</code> clauses. Typically used when indexed columns
        have unevenly distributed values, resulting in inaccurate
        <span class="bold"><strong>cardinality</strong></span> estimates.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_cardinality">cardinality</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>.</p></dd><dt><a name="glos_index_prefix"></a><span class="glossterm">index prefix</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395969024"></a>
        In an <span class="bold"><strong>index</strong></span> that applies to
        multiple columns (known as a <span class="bold"><strong>composite
        index</strong></span>), the initial or leading columns of the index.
        A query that references the first 1, 2, 3, and so on columns of
        a composite index can use the index, even if the query does not
        reference all the columns in the index.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_composite_index">composite index</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>.</p></dd><dt><a name="glos_index_statistics"></a><span class="glossterm">index statistics</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_statistics">statistics</a>.</p></dd><dt><a name="glos_infimum_record"></a><span class="glossterm">infimum record</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395962880"></a>
        A <span class="bold"><strong>pseudo-record</strong></span> in an
        <span class="bold"><strong>index</strong></span>, representing the
        <span class="bold"><strong>gap</strong></span> below the smallest value in
        that index. If a transaction has a statement such as
        <code class="literal">SELECT ... FROM ... WHERE col &lt; 10 FOR
        UPDATE;</code>, and the smallest value in the column is 5, it
        is a lock on the infimum record that prevents other transactions
        from inserting even smaller values such as 0, -10, and so on.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_gap">gap</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_pseudo_record">pseudo-record</a>, <a class="glossseealso" href="glossary.html#glos_supremum_record">supremum record</a>.</p></dd><dt><a name="glos_information_schema"></a><span class="glossterm">INFORMATION_SCHEMA</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395955472"></a>
        The name of the <span class="bold"><strong>database</strong></span> that
        provides a query interface to the MySQL
        <span class="bold"><strong>data dictionary</strong></span>. (This name is
        defined by the ANSI SQL standard.) To examine information
        (metadata) about the database, you can query tables such as
        <code class="literal">INFORMATION_SCHEMA.TABLES</code> and
        <code class="literal">INFORMATION_SCHEMA.COLUMNS</code>, rather than using
        <code class="literal">SHOW</code> commands that produce unstructured
        output.
      </p><p>
        The <code class="literal">INFORMATION_SCHEMA</code> database also contains
        tables specific to <span class="bold"><strong>InnoDB</strong></span> that
        provide a query interface to the <code class="literal">InnoDB</code> data
        dictionary. You use these tables not to see how the database is
        structured, but to get real-time information about the workings
        of <code class="literal">InnoDB</code> tables to help with performance
        monitoring, tuning, and troubleshooting.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_data_dictionary">data dictionary</a>, <a class="glossseealso" href="glossary.html#glos_database">database</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>.</p></dd><dt><a name="glos_innodb"></a><span class="glossterm">InnoDB</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395944432"></a>
        A MySQL component that combines high performance with
        <span class="bold"><strong>transactional</strong></span> capability for
        reliability, robustness, and concurrent access. It embodies the
        <span class="bold"><strong>ACID</strong></span> design philosophy.
        Represented as a <span class="bold"><strong>storage
        engine</strong></span>; it handles tables created or altered with the
        <code class="literal">ENGINE=INNODB</code> clause. See
        <a class="xref" href="innodb-storage-engine.html" title="Chapter 15 The InnoDB Storage Engine">Chapter 15, <i>The InnoDB Storage Engine</i></a> for architectural
        details and administration procedures, and
        <a class="xref" href="optimization.html#optimizing-innodb" title="8.5 Optimizing for InnoDB Tables">Section 8.5, “Optimizing for InnoDB Tables”</a> for performance advice.
      </p><p>
        In MySQL 5.5 and higher, <code class="literal">InnoDB</code> is the
        default storage engine for new tables and the
        <code class="literal">ENGINE=INNODB</code> clause is not required.
      </p><p>
        <code class="literal">InnoDB</code> tables are ideally suited for
        <span class="bold"><strong>hot backups</strong></span>. See
        <a class="xref" href="mysql-enterprise.html#mysql-enterprise-backup" title="29.2 MySQL Enterprise Backup Overview">Section 29.2, “MySQL Enterprise Backup Overview”</a> for information about
        the <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product for backing up MySQL servers without interrupting normal
        processing.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_storage_engine">storage engine</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_innodb_autoinc_lock_mode"></a><span class="glossterm">innodb_autoinc_lock_mode</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395929968"></a>
        The <a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode</code></a>
        option controls the algorithm used for
        <span class="bold"><strong>auto-increment locking</strong></span>. When
        you have an auto-incrementing <span class="bold"><strong>primary
        key</strong></span>, you can use statement-based replication only
        with the setting
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode=1</code></a>.
        This setting is known as <span class="emphasis"><em>consecutive</em></span> lock
        mode, because multi-row inserts within a transaction receive
        consecutive auto-increment values. If you have
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode=2</code></a>,
        which allows higher concurrency for insert operations, use
        row-based replication rather than statement-based replication.
        This setting is known as <span class="emphasis"><em>interleaved</em></span> lock
        mode, because multiple multi-row insert statements running at
        the same time can receive
        <span class="bold"><strong>auto-increment</strong></span> values that are
        interleaved. The setting
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode=0</code></a>
        should not be used except for compatibility purposes.
      </p><p>
        Consecutive lock mode
        (<a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode=1</code></a>) is
        the default setting prior to MySQL 8.0.3. As of MySQL 8.0.3,
        interleaved lock mode
        (<a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode=2</code></a>) is
        the default, which reflects the change from statement-based to
        row-based replication as the default replication type.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_auto_increment">auto-increment</a>, <a class="glossseealso" href="glossary.html#glos_auto_increment_locking">auto-increment locking</a>, <a class="glossseealso" href="glossary.html#glos_mixed_mode_insert">mixed-mode insert</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>.</p></dd><dt><a name="glos_innodb_file_per_table"></a><span class="glossterm">innodb_file_per_table</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395913584"></a>
        An important configuration option that affects many aspects of
        <code class="literal">InnoDB</code> file storage, availability of
        features, and I/O characteristics. In MySQL 5.6.7 and higher, it
        is enabled by default. The
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_file_per_table"><code class="literal">innodb_file_per_table</code></a> option
        turns on <span class="bold"><strong>file-per-table</strong></span> mode.
        With this mode enabled, a newly created
        <code class="literal">InnoDB</code> table and associated indexes can be
        stored in a file-per-table <span class="bold"><strong>.ibd
        file</strong></span>, outside the <span class="bold"><strong>system
        tablespace</strong></span>.
      </p><p>
        This option affects the performance and storage considerations
        for a number of SQL statements, such as
        <a class="link" href="sql-syntax.html#drop-table" title="13.1.29 DROP TABLE Syntax"><code class="literal">DROP TABLE</code></a> and
        <a class="link" href="sql-syntax.html#truncate-table" title="13.1.34 TRUNCATE TABLE Syntax"><code class="literal">TRUNCATE TABLE</code></a>.
      </p><p>
        Enabling the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_file_per_table"><code class="literal">innodb_file_per_table</code></a> option
        allows you to take advantage of features such as table
        <span class="bold"><strong>compression</strong></span> and named-table
        backups in <span class="bold"><strong>MySQL Enterprise
        Backup</strong></span>.
      </p><p>
        For more information, see
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_file_per_table"><code class="literal">innodb_file_per_table</code></a>, and
        <a class="xref" href="innodb-storage-engine.html#innodb-multiple-tablespaces" title="15.7.4 InnoDB File-Per-Table Tablespaces">Section 15.7.4, “InnoDB File-Per-Table Tablespaces”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_compression">compression</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>.</p></dd><dt><a name="glos_innodb_lock_wait_timeout"></a><span class="glossterm">innodb_lock_wait_timeout</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395894992"></a>
        The <a class="link" href="innodb-storage-engine.html#sysvar_innodb_lock_wait_timeout"><code class="literal">innodb_lock_wait_timeout</code></a>
        option sets the balance between
        <span class="bold"><strong>waiting</strong></span> for shared resources to
        become available, or giving up and handling the error, retrying,
        or doing alternative processing in your application. Rolls back
        any <code class="literal">InnoDB</code> transaction that waits more than a
        specified time to acquire a
        <span class="bold"><strong>lock</strong></span>. Especially useful if
        <span class="bold"><strong>deadlocks</strong></span> are caused by updates
        to multiple tables controlled by different storage engines; such
        deadlocks are not <span class="bold"><strong>detected</strong></span>
        automatically.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_deadlock">deadlock</a>, <a class="glossseealso" href="glossary.html#glos_deadlock_detection">deadlock detection</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_wait">wait</a>.</p></dd><dt><a name="glos_innodb_strict_mode"></a><span class="glossterm">innodb_strict_mode</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395885616"></a>
        The <a class="link" href="innodb-storage-engine.html#sysvar_innodb_strict_mode"><code class="literal">innodb_strict_mode</code></a> option
        controls whether <code class="literal">InnoDB</code> operates in
        <span class="bold"><strong>strict mode</strong></span>, where conditions
        that are normally treated as warnings, cause errors instead (and
        the underlying statements fail).
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_strict_mode">strict mode</a>.</p></dd><dt><a name="glos_insert"></a><span class="glossterm">insert</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395880192"></a>
        One of the primary <span class="bold"><strong>DML</strong></span>
        operations in <span class="bold"><strong>SQL</strong></span>. The
        performance of inserts is a key factor in
        <span class="bold"><strong>data warehouse</strong></span> systems that
        load millions of rows into tables, and
        <span class="bold"><strong>OLTP</strong></span> systems where many
        concurrent connections might insert rows into the same table, in
        arbitrary order. If insert performance is important to you, you
        should learn about <span class="bold"><strong>InnoDB</strong></span>
        features such as the <span class="bold"><strong>insert
        buffer</strong></span> used in <span class="bold"><strong>change
        buffering</strong></span>, and
        <span class="bold"><strong>auto-increment</strong></span> columns.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_auto_increment">auto-increment</a>, <a class="glossseealso" href="glossary.html#glos_change_buffering">change buffering</a>, <a class="glossseealso" href="glossary.html#glos_data_warehouse">data warehouse</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_insert_buffer">insert buffer</a>, <a class="glossseealso" href="glossary.html#glos_oltp">OLTP</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>.</p></dd><dt><a name="glos_insert_buffer"></a><span class="glossterm">insert buffer</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395868000"></a>
        The former name of the <span class="bold"><strong>change
        buffer</strong></span>. In MySQL 5.5, support was added for buffering
        changes to secondary index pages for
        <a class="link" href="sql-syntax.html#delete" title="13.2.2 DELETE Syntax"><code class="literal">DELETE</code></a> and
        <a class="link" href="sql-syntax.html#update" title="13.2.12 UPDATE Syntax"><code class="literal">UPDATE</code></a> operations. Previously,
        only changes resulting from
        <a class="link" href="sql-syntax.html#insert" title="13.2.6 INSERT Syntax"><code class="literal">INSERT</code></a> operations were buffered.
        The preferred term is now <span class="emphasis"><em>change buffer</em></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_change_buffer">change buffer</a>, <a class="glossseealso" href="glossary.html#glos_change_buffering">change buffering</a>.</p></dd><dt><a name="glos_insert_buffering"></a><span class="glossterm">insert buffering</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395859904"></a>
        The technique of storing changes to secondary index pages,
        resulting from <a class="link" href="sql-syntax.html#insert" title="13.2.6 INSERT Syntax"><code class="literal">INSERT</code></a> operations,
        in the <span class="bold"><strong>change buffer</strong></span> rather
        than writing the changes immediately, so that the physical
        writes can be performed to minimize random I/O. It is one of the
        types of <span class="bold"><strong>change buffering</strong></span>; the
        others are <span class="bold"><strong>delete buffering</strong></span> and
        <span class="bold"><strong>purge buffering</strong></span>.
      </p><p>
        Insert buffering is not used if the secondary index is
        <span class="bold"><strong>unique</strong></span>, because the uniqueness
        of new values cannot be verified before the new entries are
        written out. Other kinds of change buffering do work for unique
        indexes.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_change_buffer">change buffer</a>, <a class="glossseealso" href="glossary.html#glos_change_buffering">change buffering</a>, <a class="glossseealso" href="glossary.html#glos_delete_buffering">delete buffering</a>, <a class="glossseealso" href="glossary.html#glos_insert_buffer">insert buffer</a>, <a class="glossseealso" href="glossary.html#glos_purge_buffering">purge buffering</a>, <a class="glossseealso" href="glossary.html#glos_unique_index">unique index</a>.</p></dd><dt><a name="glos_insert_intention_lock"></a><span class="glossterm">insert intention lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395848704"></a>
        A type of <span class="bold"><strong>gap lock</strong></span> that is set
        by <a class="link" href="sql-syntax.html#insert" title="13.2.6 INSERT Syntax"><code class="literal">INSERT</code></a> operations prior to row
        insertion. This type of <span class="bold"><strong>lock</strong></span>
        signals the intent to insert in such a way that multiple
        transactions inserting into the same index gap need not wait for
        each other if they are not inserting at the same position within
        the gap. For more information, see
        <a class="xref" href="innodb-storage-engine.html#innodb-locking" title="15.5.1 InnoDB Locking">Section 15.5.1, “InnoDB Locking”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_gap_lock">gap lock</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_next_key_lock">next-key lock</a>.</p></dd><dt><a name="glos_instance"></a><span class="glossterm">instance</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395841488"></a>
        A single <span class="bold"><strong>mysqld</strong></span> daemon managing
        a <span class="bold"><strong>data directory</strong></span> representing
        one or more <span class="bold"><strong>databases</strong></span> with a
        set of <span class="bold"><strong>tables</strong></span>. It is common in
        development, testing, and some
        <span class="bold"><strong>replication</strong></span> scenarios to have
        multiple instances on the same
        <span class="bold"><strong>server</strong></span> machine, each managing
        its own data directory and listening on its own port or socket.
        With one instance running a
        <span class="bold"><strong>disk-bound</strong></span> workload, the server
        might still have extra CPU and memory capacity to run additional
        instances.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_data_directory">data directory</a>, <a class="glossseealso" href="glossary.html#glos_database">database</a>, <a class="glossseealso" href="glossary.html#glos_disk_bound">disk-bound</a>, <a class="glossseealso" href="glossary.html#glos_mysqld">mysqld</a>, <a class="glossseealso" href="glossary.html#glos_replication">replication</a>, <a class="glossseealso" href="glossary.html#glos_server">server</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_instrumentation"></a><span class="glossterm">instrumentation</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395830320"></a>
        Modifications at the source code level to collect performance
        data for tuning and debugging. In MySQL, data collected by
        instrumentation is exposed through an SQL interface using the
        <code class="literal">INFORMATION_SCHEMA</code> and
        <code class="literal">PERFORMANCE_SCHEMA</code> databases.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_information_schema">INFORMATION_SCHEMA</a>, <a class="glossseealso" href="glossary.html#glos_performance_schema">Performance Schema</a>.</p></dd><dt><a name="glos_intention_exclusive_lock"></a><span class="glossterm">intention exclusive lock</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_intention_lock">intention lock</a>.</p></dd><dt><a name="glos_intention_lock"></a><span class="glossterm">intention lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395824160"></a>
        A kind of <span class="bold"><strong>lock</strong></span> that applies to
        the table, used to indicate the kind of lock the
        <span class="bold"><strong>transaction</strong></span> intends to acquire
        on rows in the table. Different transactions can acquire
        different kinds of intention locks on the same table, but the
        first transaction to acquire an <span class="emphasis"><em>intention
        exclusive</em></span> (IX) lock on a table prevents other
        transactions from acquiring any S or X locks on the table.
        Conversely, the first transaction to acquire an
        <span class="emphasis"><em>intention shared</em></span> (IS) lock on a table
        prevents other transactions from acquiring any X locks on the
        table. The two-phase process allows the lock requests to be
        resolved in order, without blocking locks and corresponding
        operations that are compatible. For more information about this
        locking mechanism, see <a class="xref" href="innodb-storage-engine.html#innodb-locking" title="15.5.1 InnoDB Locking">Section 15.5.1, “InnoDB Locking”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_lock_mode">lock mode</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_intention_shared_lock"></a><span class="glossterm">intention shared lock</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_intention_lock">intention lock</a>.</p></dd><dt><a name="glos_inverted_index"></a><span class="glossterm">inverted index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395814976"></a>
        A data structure optimized for document retrieval systems, used
        in the implementation of <code class="literal">InnoDB</code>
        <span class="bold"><strong>full-text search</strong></span>. The
        <code class="literal">InnoDB</code> <span class="bold"><strong>FULLTEXT
        index</strong></span>, implemented as an inverted index, records the
        position of each word within a document, rather than the
        location of a table row. A single column value (a document
        stored as a text string) is represented by many entries in the
        inverted index.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_full_text_search">full-text search</a>, <a class="glossseealso" href="glossary.html#glos_fulltext_index">FULLTEXT index</a>, <a class="glossseealso" href="glossary.html#glos_ilist">ilist</a>.</p></dd><dt><a name="glos_iops"></a><span class="glossterm">IOPS</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395808240"></a>
        Acronym for <span class="bold"><strong>I/O operations per
        second</strong></span>. A common measurement for busy systems,
        particularly <span class="bold"><strong>OLTP</strong></span> applications.
        If this value is near the maximum that the storage devices can
        handle, the application can become
        <span class="bold"><strong>disk-bound</strong></span>, limiting
        <span class="bold"><strong>scalability</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_disk_bound">disk-bound</a>, <a class="glossseealso" href="glossary.html#glos_oltp">OLTP</a>, <a class="glossseealso" href="glossary.html#glos_scalability">scalability</a>.</p></dd><dt><a name="glos_isolation_level"></a><span class="glossterm">isolation level</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395801616"></a>
        One of the foundations of database processing. Isolation is the
        <span class="bold"><strong>I</strong></span> in the acronym
        <span class="bold"><strong>ACID</strong></span>; the isolation level is
        the setting that fine-tunes the balance between performance and
        reliability, consistency, and reproducibility of results when
        multiple <span class="bold"><strong>transactions</strong></span> are
        making changes and performing queries at the same time.
      </p><p>
        From highest amount of consistency and protection to the least,
        the isolation levels supported by InnoDB are:
        <span class="bold"><strong>SERIALIZABLE</strong></span>,
        <span class="bold"><strong>REPEATABLE READ</strong></span>,
        <span class="bold"><strong>READ COMMITTED</strong></span>, and
        <span class="bold"><strong>READ UNCOMMITTED</strong></span>.
      </p><p>
        With <code class="literal">InnoDB</code> tables, many users can keep the
        default isolation level (<span class="emphasis"><em>REPEATABLE READ</em></span>)
        for all operations. Expert users might choose the
        <span class="bold"><strong>READ COMMITTED</strong></span> level as they
        push the boundaries of scalability with
        <span class="bold"><strong>OLTP</strong></span> processing, or during data
        warehousing operations where minor inconsistencies do not affect
        the aggregate results of large amounts of data. The levels on
        the edges (<span class="bold"><strong>SERIALIZABLE</strong></span> and
        <span class="bold"><strong>READ UNCOMMITTED</strong></span>) change the
        processing behavior to such an extent that they are rarely used.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_oltp">OLTP</a>, <a class="glossseealso" href="glossary.html#glos_read_committed">READ COMMITTED</a>, <a class="glossseealso" href="glossary.html#glos_read_uncommitted">READ UNCOMMITTED</a>, <a class="glossseealso" href="glossary.html#glos_repeatable_read">REPEATABLE READ</a>, <a class="glossseealso" href="glossary.html#glos_serializable">SERIALIZABLE</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">J</h3>
<dl><dt><a name="glos_join"></a><span class="glossterm">join</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395784608"></a>
        A <span class="bold"><strong>query</strong></span> that retrieves data
        from more than one table, by referencing columns in the tables
        that hold identical values. Ideally, these columns are part of
        an <code class="literal">InnoDB</code> <span class="bold"><strong>foreign
        key</strong></span> relationship, which ensures
        <span class="bold"><strong>referential integrity</strong></span> and that
        the join columns are <span class="bold"><strong>indexed</strong></span>.
        Often used to save space and improve query performance by
        replacing repeated strings with numeric IDs, in a
        <span class="bold"><strong>normalized</strong></span> data design.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_foreign_key">foreign key</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_normalized">normalized</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>, <a class="glossseealso" href="glossary.html#glos_referential_integrity">referential integrity</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">K</h3>
<dl><dt><a name="glos_key_block_size"></a><span class="glossterm">KEY_BLOCK_SIZE</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395774848"></a>
        An option to specify the size of data pages within an
        <code class="literal">InnoDB</code> table that uses
        <span class="bold"><strong>compressed row format</strong></span>. The
        default is 8 kilobytes. Lower values risk hitting internal
        limits that depend on the combination of row size and
        compression percentage.
      </p><p>
        For <a class="link" href="storage-engines.html#myisam-storage-engine" title="16.2 The MyISAM Storage Engine"><code class="literal">MyISAM</code></a> tables,
        <code class="literal">KEY_BLOCK_SIZE</code> optionally specifies the size
        in bytes to use for index key blocks. The value is treated as a
        hint; a different size could be used if necessary. A
        <code class="literal">KEY_BLOCK_SIZE</code> value specified for an
        individual index definition overrides a table-level
        <code class="literal">KEY_BLOCK_SIZE</code> value.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_compressed_row_format">compressed row format</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">L</h3>
<dl><dt><a name="glos_latch"></a><span class="glossterm">latch</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395765952"></a>
        A lightweight structure used by <code class="literal">InnoDB</code> to
        implement a <span class="bold"><strong>lock</strong></span> for its own
        internal memory structures, typically held for a brief time
        measured in milliseconds or microseconds. A general term that
        includes both <span class="bold"><strong>mutexes</strong></span> (for
        exclusive access) and <span class="bold"><strong>rw-locks</strong></span>
        (for shared access). Certain latches are the focus of
        <code class="literal">InnoDB</code> performance tuning. Statistics about
        latch use and contention are available through the
        <span class="bold"><strong>Performance Schema</strong></span> interface.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_mutex">mutex</a>, <a class="glossseealso" href="glossary.html#glos_performance_schema">Performance Schema</a>, <a class="glossseealso" href="glossary.html#glos_rw_lock">rw-lock</a>.</p></dd><dt><a name="glos_list"></a><span class="glossterm">list</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395756640"></a>
        The <code class="literal">InnoDB</code> <span class="bold"><strong>buffer
        pool</strong></span> is represented as a list of memory
        <span class="bold"><strong>pages</strong></span>. The list is reordered as
        new pages are accessed and enter the buffer pool, as pages
        within the buffer pool are accessed again and are considered
        newer, and as pages that are not accessed for a long time are
        <span class="bold"><strong>evicted</strong></span> from the buffer pool.
        The buffer pool is divided into
        <span class="bold"><strong>sublists</strong></span>, and the replacement
        policy is a variation of the familiar
        <span class="bold"><strong>LRU</strong></span> technique.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_eviction">eviction</a>, <a class="glossseealso" href="glossary.html#glos_lru">LRU</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_sublist">sublist</a>.</p></dd><dt><a name="glos_lock"></a><span class="glossterm">lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395747376"></a>
        The high-level notion of an object that controls access to a
        resource, such as a table, row, or internal data structure, as
        part of a <span class="bold"><strong>locking</strong></span> strategy. For
        intensive performance tuning, you might delve into the actual
        structures that implement locks, such as
        <span class="bold"><strong>mutexes</strong></span> and
        <span class="bold"><strong>latches</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_latch">latch</a>, <a class="glossseealso" href="glossary.html#glos_lock_mode">lock mode</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_mutex">mutex</a>.</p></dd><dt><a name="glos_lock_escalation"></a><span class="glossterm">lock escalation</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395740704"></a>
        An operation used in some database systems that converts many
        <span class="bold"><strong>row locks</strong></span> into a single
        <span class="bold"><strong>table lock</strong></span>, saving memory space
        but reducing concurrent access to the table.
        <code class="literal">InnoDB</code> uses a space-efficient representation
        for row locks, so that <span class="bold"><strong>lock</strong></span>
        escalation is not needed.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_row_lock">row lock</a>, <a class="glossseealso" href="glossary.html#glos_table_lock">table lock</a>.</p></dd><dt><a name="glos_lock_mode"></a><span class="glossterm">lock mode</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395734000"></a>
        A shared (S) <span class="bold"><strong>lock</strong></span> allows a
        <span class="bold"><strong>transaction</strong></span> to read a row.
        Multiple transactions can acquire an S lock on that same row at
        the same time.
      </p><p>
        An exclusive (X) lock allows a transaction to update or delete a
        row. No other transaction can acquire any kind of lock on that
        same row at the same time.
      </p><p>
        <span class="bold"><strong>Intention locks</strong></span> apply to the
        table, and are used to indicate what kind of lock the
        transaction intends to acquire on rows in the table. Different
        transactions can acquire different kinds of intention locks on
        the same table, but the first transaction to acquire an
        intention exclusive (IX) lock on a table prevents other
        transactions from acquiring any S or X locks on the table.
        Conversely, the first transaction to acquire an intention shared
        (IS) lock on a table prevents other transactions from acquiring
        any X locks on the table. The two-phase process allows the lock
        requests to be resolved in order, without blocking locks and
        corresponding operations that are compatible.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_intention_lock">intention lock</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_locking"></a><span class="glossterm">locking</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395725136"></a>
        The system of protecting a
        <span class="bold"><strong>transaction</strong></span> from seeing or
        changing data that is being queried or changed by other
        transactions. The <span class="bold"><strong>locking</strong></span>
        strategy must balance reliability and consistency of database
        operations (the principles of the
        <span class="bold"><strong>ACID</strong></span> philosophy) against the
        performance needed for good
        <span class="bold"><strong>concurrency</strong></span>. Fine-tuning the
        locking strategy often involves choosing an
        <span class="bold"><strong>isolation level</strong></span> and ensuring
        all your database operations are safe and reliable for that
        isolation level.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_locking_read"></a><span class="glossterm">locking read</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395716448"></a>
        A <a class="link" href="sql-syntax.html#select" title="13.2.10 SELECT Syntax"><code class="literal">SELECT</code></a> statement that also
        performs a <span class="bold"><strong>locking</strong></span> operation on
        an <code class="literal">InnoDB</code> table. Either <code class="literal">SELECT ...
        FOR UPDATE</code> or <code class="literal">SELECT ...
        LOCK IN SHARE MODE</code>. It has the potential to produce a
        <span class="bold"><strong>deadlock</strong></span>, depending on the
        <span class="bold"><strong>isolation level</strong></span> of the
        transaction. The opposite of a <span class="bold"><strong>non-locking
        read</strong></span>. Not allowed for global tables in a
        <span class="bold"><strong>read-only transaction</strong></span>.
      </p><p>
        <code class="literal">SELECT ... FOR SHARE</code> replaces <code class="literal">SELECT
        ... LOCK IN SHARE MODE</code> in MySQL 8.0.1, but
        <code class="literal">LOCK IN SHARE MODE</code> remains available for
        backward compatibility.
      </p><p>
        See <a class="xref" href="innodb-storage-engine.html#innodb-locking-reads" title="15.5.2.4 Locking Reads">Section 15.5.2.4, “Locking Reads”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_deadlock">deadlock</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_non_locking_read">non-locking read</a>, <a class="glossseealso" href="glossary.html#glos_read_only_transaction">read-only transaction</a>.</p></dd><dt><a name="glos_log"></a><span class="glossterm">log</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395700368"></a>
        In the <code class="literal">InnoDB</code> context, <span class="quote">“<span class="quote">log</span>”</span> or
        <span class="quote">“<span class="quote">log files</span>”</span> typically refers to the
        <span class="bold"><strong>redo log</strong></span> represented by the
        <span class="bold"><strong>ib_logfile<em class="replaceable"><code>N</code></em></strong></span>
        files. Another type of <code class="literal">InnoDB</code> log is the
        <span class="bold"><strong>undo log</strong></span>, which is a storage
        area that holds copies of data modified by active transactions.
      </p><p>
        Other kinds of logs that are important in MySQL are the
        <span class="bold"><strong>error log</strong></span> (for diagnosing
        startup and runtime problems), <span class="bold"><strong>binary
        log</strong></span> (for working with replication and performing
        point-in-time restores), the <span class="bold"><strong>general query
        log</strong></span> (for diagnosing application problems), and the
        <span class="bold"><strong>slow query log</strong></span> (for diagnosing
        performance problems).
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_binary_log">binary log</a>, <a class="glossseealso" href="glossary.html#glos_error_log">error log</a>, <a class="glossseealso" href="glossary.html#glos_general_query_log">general query log</a>, <a class="glossseealso" href="glossary.html#glos_ib_logfile">ib_logfile</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>, <a class="glossseealso" href="glossary.html#glos_slow_query_log">slow query log</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>.</p></dd><dt><a name="glos_log_buffer"></a><span class="glossterm">log buffer</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395686336"></a>
        The memory area that holds data to be written to the
        <span class="bold"><strong>log files</strong></span> that make up the
        <span class="bold"><strong>redo log</strong></span>. It is controlled by
        the <a class="link" href="innodb-storage-engine.html#sysvar_innodb_log_buffer_size"><code class="literal">innodb_log_buffer_size</code></a>
        configuration option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_log_file">log file</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>.</p></dd><dt><a name="glos_log_file"></a><span class="glossterm">log file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395680432"></a>
        One of the
        <span class="bold"><strong>ib_logfile<em class="replaceable"><code>N</code></em></strong></span>
        files that make up the <span class="bold"><strong>redo
        log</strong></span>. Data is written to these files from the
        <span class="bold"><strong>log buffer</strong></span> memory area.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ib_logfile">ib_logfile</a>, <a class="glossseealso" href="glossary.html#glos_log_buffer">log buffer</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>.</p></dd><dt><a name="glos_log_group"></a><span class="glossterm">log group</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395674336"></a>
        The set of files that make up the <span class="bold"><strong>redo
        log</strong></span>, typically named <code class="literal">ib_logfile0</code>
        and <code class="literal">ib_logfile1</code>. (For that reason, sometimes
        referred to collectively as
        <span class="bold"><strong>ib_logfile</strong></span>.)
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ib_logfile">ib_logfile</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>.</p></dd><dt><a name="glos_logical"></a><span class="glossterm">logical</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395668272"></a>
        A type of operation that involves high-level, abstract aspects
        such as tables, queries, indexes, and other SQL concepts.
        Typically, logical aspects are important to make database
        administration and application development convenient and
        usable. Contrast with <span class="bold"><strong>physical</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_logical_backup">logical backup</a>, <a class="glossseealso" href="glossary.html#glos_physical">physical</a>.</p></dd><dt><a name="glos_logical_backup"></a><span class="glossterm">logical backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395664224"></a>
        A <span class="bold"><strong>backup</strong></span> that reproduces table
        structure and data, without copying the actual data files. For
        example, the
        <span class="bold"><strong><code class="literal">mysqldump</code></strong></span>
        command produces a logical backup, because its output contains
        statements such as <a class="link" href="sql-syntax.html#create-table" title="13.1.18 CREATE TABLE Syntax"><code class="literal">CREATE TABLE</code></a>
        and <a class="link" href="sql-syntax.html#insert" title="13.2.6 INSERT Syntax"><code class="literal">INSERT</code></a> that can re-create the
        data. Contrast with <span class="bold"><strong>physical
        backup</strong></span>. A logical backup offers flexibility (for
        example, you could edit table definitions or insert statements
        before restoring), but can take substantially longer to
        <span class="bold"><strong>restore</strong></span> than a physical backup.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_backup">backup</a>, <a class="glossseealso" href="glossary.html#glos_mysqldump">mysqldump</a>, <a class="glossseealso" href="glossary.html#glos_physical_backup">physical backup</a>, <a class="glossseealso" href="glossary.html#glos_restore">restore</a>.</p></dd><dt><a name="glos_loose_"></a><span class="glossterm">loose_</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395653840"></a>
        A prefix added to <code class="literal">InnoDB</code> configuration
        options after server <span class="bold"><strong>startup</strong></span>,
        so any new configuration options not recognized by the current
        level of MySQL do not cause a startup failure. MySQL processes
        configuration options that start with this prefix, but gives a
        warning rather than a failure if the part after the prefix is
        not a recognized option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_startup">startup</a>.</p></dd><dt><a name="glos_low_water_mark"></a><span class="glossterm">low-water mark</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395649344"></a>
        A value representing a lower limit, typically a threshold value
        at which some corrective action begins or becomes more
        aggressive. Contrast with <span class="bold"><strong>high-water
        mark</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_high_water_mark">high-water mark</a>.</p></dd><dt><a name="glos_lru"></a><span class="glossterm">LRU</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395645744"></a>
        An acronym for <span class="quote">“<span class="quote">least recently used</span>”</span>, a common
        method for managing storage areas. The items that have not been
        used recently are <span class="bold"><strong>evicted</strong></span> when
        space is needed to cache newer items. <code class="literal">InnoDB</code>
        uses the LRU mechanism by default to manage the
        <span class="bold"><strong>pages</strong></span> within the
        <span class="bold"><strong>buffer pool</strong></span>, but makes
        exceptions in cases where a page might be read only a single
        time, such as during a <span class="bold"><strong>full table
        scan</strong></span>. This variation of the LRU algorithm is called
        the <span class="bold"><strong>midpoint insertion
        strategy</strong></span>. For more information, see
        <a class="xref" href="innodb-storage-engine.html#innodb-buffer-pool" title="15.6.3.1 The InnoDB Buffer Pool">Section 15.6.3.1, “The InnoDB Buffer Pool”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_eviction">eviction</a>, <a class="glossseealso" href="glossary.html#glos_full_table_scan">full table scan</a>, <a class="glossseealso" href="glossary.html#glos_midpoint_insertion_strategy">midpoint insertion strategy</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>.</p></dd><dt><a name="glos_lsn"></a><span class="glossterm">LSN</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395635152"></a>
        Acronym for <span class="quote">“<span class="quote">log sequence number</span>”</span>. This arbitrary,
        ever-increasing value represents a point in time corresponding
        to operations recorded in the <span class="bold"><strong>redo
        log</strong></span>. (This point in time is regardless of
        <span class="bold"><strong>transaction</strong></span> boundaries; it can
        fall in the middle of one or more transactions.) It is used
        internally by <code class="literal">InnoDB</code> during
        <span class="bold"><strong>crash recovery</strong></span> and for managing
        the <span class="bold"><strong>buffer pool</strong></span>.
      </p><p>
        Prior to MySQL 5.6.3, the LSN was a 4-byte unsigned integer. The
        LSN became an 8-byte unsigned integer in MySQL 5.6.3 when the
        redo log file size limit increased from 4GB to 512GB, as
        additional bytes were required to store extra size information.
        Applications built on MySQL 5.6.3 or later that use LSN values
        should use 64-bit rather than 32-bit variables to store and
        compare LSN values.
      </p><p>
        In the <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product, you can specify an LSN to represent the point in time
        from which to take an <span class="bold"><strong>incremental
        backup</strong></span>. The relevant LSN is displayed by the output
        of the <span class="command"><strong>mysqlbackup</strong></span> command. Once you have the
        LSN corresponding to the time of a full backup, you can specify
        that value to take a subsequent incremental backup, whose output
        contains another LSN for the next incremental backup.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_crash_recovery">crash recovery</a>, <a class="glossseealso" href="glossary.html#glos_incremental_backup">incremental backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">M</h3>
<dl><dt><a name="glos_mrg_file"></a><span class="glossterm">.MRG file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395522544"></a>
        A file containing references to other tables, used by the
        <code class="literal">MERGE</code> storage engine. Files with this
        extension are always included in backups produced by the
        <span class="command"><strong>mysqlbackup</strong></span> command of the
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_mysqlbackup_command">mysqlbackup command</a>.</p></dd><dt><a name="glos_myd_file"></a><span class="glossterm">.MYD file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395482848"></a>
        A file that MySQL uses to store data for a
        <a class="link" href="storage-engines.html#myisam-storage-engine" title="16.2 The MyISAM Storage Engine"><code class="literal">MyISAM</code></a> table.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_myi_file">.MYI file</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_mysqlbackup_command">mysqlbackup command</a>.</p></dd><dt><a name="glos_myi_file"></a><span class="glossterm">.MYI file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395477456"></a>
        A file that MySQL uses to store indexes for a
        <a class="link" href="storage-engines.html#myisam-storage-engine" title="16.2 The MyISAM Storage Engine"><code class="literal">MyISAM</code></a> table.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_myd_file">.MYD file</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_mysqlbackup_command">mysqlbackup command</a>.</p></dd><dt><a name="glos_master_server"></a><span class="glossterm">master server</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395621024"></a>
        Frequently shortened to <span class="quote">“<span class="quote">master</span>”</span>. A database server
        machine in a <span class="bold"><strong>replication</strong></span>
        scenario that processes the initial insert, update, and delete
        requests for data. These changes are propagated to, and repeated
        on, other servers known as <span class="bold"><strong>slave
        servers</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_replication">replication</a>, <a class="glossseealso" href="glossary.html#glos_slave_server">slave server</a>.</p></dd><dt><a name="glos_master_thread"></a><span class="glossterm">master thread</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395615888"></a>
        An <code class="literal">InnoDB</code>
        <span class="bold"><strong>thread</strong></span> that performs various
        tasks in the background. Most of these tasks are I/O related,
        such as writing changes from the <span class="bold"><strong>change
        buffer</strong></span> to the appropriate secondary indexes.
      </p><p>
        To improve <span class="bold"><strong>concurrency</strong></span>,
        sometimes actions are moved from the master thread to separate
        background threads. For example, in MySQL 5.6 and higher,
        <span class="bold"><strong>dirty pages</strong></span> are
        <span class="bold"><strong>flushed</strong></span> from the
        <span class="bold"><strong>buffer pool</strong></span> by the
        <span class="bold"><strong>page cleaner</strong></span> thread rather than
        the master thread.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_change_buffer">change buffer</a>, <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_dirty_page">dirty page</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_page_cleaner">page cleaner</a>, <a class="glossseealso" href="glossary.html#glos_thread">thread</a>.</p></dd><dt><a name="glos_mdl"></a><span class="glossterm">MDL</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395603728"></a>
        Acronym for <span class="quote">“<span class="quote">metadata lock</span>”</span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_metadata_lock">metadata lock</a>.</p></dd><dt><a name="glos_memcached"></a><span class="glossterm">memcached</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395600752"></a>
        A popular component of many MySQL and
        <span class="bold"><strong>NoSQL</strong></span> software stacks, allowing
        fast reads and writes for single values and caching the results
        entirely in memory. Traditionally, applications required extra
        logic to write the same data to a MySQL database for permanent
        storage, or to read data from a MySQL database when it was not
        cached yet in memory. Now, applications can use the simple
        <span class="command"><strong>memcached</strong></span> protocol, supported by client
        libraries for many languages, to communicate directly with MySQL
        servers using <code class="literal">InnoDB</code> or
        <code class="literal">NDB</code> tables. These NoSQL interfaces to MySQL
        tables allow applications to achieve higher read and write
        performance than by issuing SQL statements directly, and can
        simplify application logic and deployment configurations for
        systems that already incorporate <span class="command"><strong>memcached</strong></span>
        for in-memory caching.
      </p><p>
        The <span class="command"><strong>memcached</strong></span> interface to
        <code class="literal">InnoDB</code> tables is available in MySQL 5.6 and
        higher; see <a class="xref" href="innodb-storage-engine.html#innodb-memcached" title="15.19 InnoDB memcached Plugin">Section 15.19, “InnoDB memcached Plugin”</a> for details. The
        <span class="command"><strong>memcached</strong></span> interface to <code class="literal">NDB</code>
        tables is available in NDB Cluster 7.2 and later; see
        <a class="ulink" href="http://dev.mysql.com/doc/ndbapi/en/ndbmemcache.html" target="_top">http://dev.mysql.com/doc/ndbapi/en/ndbmemcache.html</a>
        for details.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_nosql">NoSQL</a>.</p></dd><dt><a name="glos_merge"></a><span class="glossterm">merge</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395588064"></a>
        To apply changes to data cached in memory, such as when a page
        is brought into the <span class="bold"><strong>buffer
        pool</strong></span>, and any applicable changes recorded in the
        <span class="bold"><strong>change buffer</strong></span> are incorporated
        into the page in the buffer pool. The updated data is eventually
        written to the <span class="bold"><strong>tablespace</strong></span> by
        the <span class="bold"><strong>flush</strong></span> mechanism.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_change_buffer">change buffer</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>.</p></dd><dt><a name="glos_metadata_lock"></a><span class="glossterm">metadata lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395580848"></a>
        A type of <span class="bold"><strong>lock</strong></span> that prevents
        <span class="bold"><strong>DDL</strong></span> operations on a table that
        is being used at the same time by another
        <span class="bold"><strong>transaction</strong></span>. For details, see
        <a class="xref" href="optimization.html#metadata-locking" title="8.11.4 Metadata Locking">Section 8.11.4, “Metadata Locking”</a>.
      </p><p>
        Enhancements to <span class="bold"><strong>online</strong></span>
        operations, particularly in MySQL 5.6 and higher, are focused on
        reducing the amount of metadata locking. The objective is for
        DDL operations that do not change the table structure (such as
        <a class="link" href="sql-syntax.html#create-index" title="13.1.14 CREATE INDEX Syntax"><code class="literal">CREATE INDEX</code></a> and
        <a class="link" href="sql-syntax.html#drop-index" title="13.1.25 DROP INDEX Syntax"><code class="literal">DROP INDEX</code></a> for
        <code class="literal">InnoDB</code> tables) to proceed while the table is
        being queried, updated, and so on by other transactions.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_online">online</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_metrics_counter"></a><span class="glossterm">metrics counter</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395569152"></a>
        A feature implemented by the
        <a class="link" href="information-schema.html#innodb-metrics-table" title="24.33.16 The INFORMATION_SCHEMA INNODB_METRICS Table"><code class="literal">INNODB_METRICS</code></a> table in the
        <span class="bold"><strong>INFORMATION_SCEMA</strong></span>, in MySQL 5.6
        and higher. You can query
        <span class="bold"><strong>counts</strong></span> and totals for low-level
        <code class="literal">InnoDB</code> operations, and use the results for
        performance tuning in combination with data from the
        <span class="bold"><strong>Performance Schema</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_counter">counter</a>, <a class="glossseealso" href="glossary.html#glos_information_schema">INFORMATION_SCHEMA</a>, <a class="glossseealso" href="glossary.html#glos_performance_schema">Performance Schema</a>.</p></dd><dt><a name="glos_midpoint_insertion_strategy"></a><span class="glossterm">midpoint insertion strategy</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395561152"></a>
        The technique of initially bringing
        <span class="bold"><strong>pages</strong></span> into the
        <code class="literal">InnoDB</code> <span class="bold"><strong>buffer
        pool</strong></span> not at the <span class="quote">“<span class="quote">newest</span>”</span> end of the
        list, but instead somewhere in the middle. The exact location of
        this point can vary, based on the setting of the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_old_blocks_pct"><code class="literal">innodb_old_blocks_pct</code></a> option.
        The intent is that pages that are only read once, such as during
        a <span class="bold"><strong>full table scan</strong></span>, can be aged
        out of the buffer pool sooner than with a strict
        <span class="bold"><strong>LRU</strong></span> algorithm. For more
        information, see <a class="xref" href="innodb-storage-engine.html#innodb-buffer-pool" title="15.6.3.1 The InnoDB Buffer Pool">Section 15.6.3.1, “The InnoDB Buffer Pool”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_full_table_scan">full table scan</a>, <a class="glossseealso" href="glossary.html#glos_lru">LRU</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>.</p></dd><dt><a name="glos_mini_transaction"></a><span class="glossterm">mini-transaction</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395550784"></a>
        An internal phase of <code class="literal">InnoDB</code> processing, when
        making changes at the <span class="bold"><strong>physical</strong></span>
        level to internal data structures during
        <span class="bold"><strong>DML</strong></span> operations. A
        mini-transaction (mtr) has no notion of
        <span class="bold"><strong>rollback</strong></span>; multiple
        mini-transactions can occur within a single
        <span class="bold"><strong>transaction</strong></span>. Mini-transactions
        write information to the <span class="bold"><strong>redo
        log</strong></span> that is used during <span class="bold"><strong>crash
        recovery</strong></span>. A mini-transaction can also happen outside
        the context of a regular transaction, for example during
        <span class="bold"><strong>purge</strong></span> processing by background
        threads.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_crash_recovery">crash recovery</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_physical">physical</a>, <a class="glossseealso" href="glossary.html#glos_purge">purge</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_mixed_mode_insert"></a><span class="glossterm">mixed-mode insert</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395538528"></a>
        An <a class="link" href="sql-syntax.html#insert" title="13.2.6 INSERT Syntax"><code class="literal">INSERT</code></a> statement where
        <span class="bold"><strong>auto-increment</strong></span> values are
        specified for some but not all of the new rows. For example, a
        multi-value <code class="literal">INSERT</code> could specify a value for
        the auto-increment column in some cases and
        <code class="literal">NULL</code> in other cases.
        <code class="literal">InnoDB</code> generates auto-increment values for
        the rows where the column value was specified as
        <code class="literal">NULL</code>. Another example is an
        <a class="link" href="sql-syntax.html#insert-on-duplicate" title="13.2.6.2 INSERT ... ON DUPLICATE KEY UPDATE Syntax"><code class="literal">INSERT ...
        ON DUPLICATE KEY UPDATE</code></a> statement, where
        auto-increment values might be generated but not used, for any
        duplicate rows that are processed as <code class="literal">UPDATE</code>
        rather than <code class="literal">INSERT</code> statements.
      </p><p>
        Can cause consistency issues between
        <span class="bold"><strong>master</strong></span> and
        <span class="bold"><strong>slave</strong></span> servers in a
        <span class="bold"><strong>replication</strong></span> configuration. Can
        require adjusting the value of the
        <span class="bold"><strong>innodb_autoinc_lock_mode</strong></span>
        configuration option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_auto_increment">auto-increment</a>, <a class="glossseealso" href="glossary.html#glos_innodb_autoinc_lock_mode">innodb_autoinc_lock_mode</a>, <a class="glossseealso" href="glossary.html#glos_master_server">master server</a>, <a class="glossseealso" href="glossary.html#glos_replication">replication</a>, <a class="glossseealso" href="glossary.html#glos_slave_server">slave server</a>.</p></dd><dt><a name="glos_mtr"></a><span class="glossterm">mtr</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_mini_transaction">mini-transaction</a>.</p></dd><dt><a name="glos_multi_core"></a><span class="glossterm">multi-core</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395515344"></a>
        A type of processor that can take advantage of multi-threaded
        programs, such as the MySQL server.
      </p></dd><dt><a name="glos_multiversion_concurrency_control"></a><span class="glossterm">multiversion concurrency control</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_mvcc">MVCC</a>.</p></dd><dt><a name="glos_mutex"></a><span class="glossterm">mutex</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395511760"></a>
        Informal abbreviation for <span class="quote">“<span class="quote">mutex variable</span>”</span>. (Mutex
        itself is short for <span class="quote">“<span class="quote">mutual exclusion</span>”</span>.) The
        low-level object that <code class="literal">InnoDB</code> uses to
        represent and enforce exclusive-access
        <span class="bold"><strong>locks</strong></span> to internal in-memory
        data structures. Once the lock is acquired, any other process,
        thread, and so on is prevented from acquiring the same lock.
        Contrast with <span class="bold"><strong>rw-locks</strong></span>, which
        <code class="literal">InnoDB</code> uses to represent and enforce
        shared-access <span class="bold"><strong>locks</strong></span> to internal
        in-memory data structures. Mutexes and rw-locks are known
        collectively as <span class="bold"><strong>latches</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_latch">latch</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_performance_schema">Performance Schema</a>, <a class="glossseealso" href="glossary.html#glos_pthreads">Pthreads</a>, <a class="glossseealso" href="glossary.html#glos_rw_lock">rw-lock</a>.</p></dd><dt><a name="glos_mvcc"></a><span class="glossterm">MVCC</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395501472"></a>
        Acronym for <span class="quote">“<span class="quote">multiversion concurrency control</span>”</span>.
        This technique lets <code class="literal">InnoDB</code>
        <span class="bold"><strong>transactions</strong></span> with certain
        <span class="bold"><strong>isolation levels</strong></span> perform
        <span class="bold"><strong>consistent read</strong></span> operations;
        that is, to query rows that are being updated by other
        transactions, and see the values from before those updates
        occurred. This is a powerful technique to increase
        <span class="bold"><strong>concurrency</strong></span>, by allowing
        queries to proceed without waiting due to
        <span class="bold"><strong>locks</strong></span> held by the other
        transactions.
      </p><p>
        This technique is not universal in the database world. Some
        other database products, and some other MySQL storage engines,
        do not support it.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_consistent_read">consistent read</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_my_cnf"></a><span class="glossterm">my.cnf</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395490752"></a>
        The name, on Unix or Linux systems, of the MySQL
        <span class="bold"><strong>option file</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_my_ini">my.ini</a>, <a class="glossseealso" href="glossary.html#glos_option_file">option file</a>.</p></dd><dt><a name="glos_my_ini"></a><span class="glossterm">my.ini</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395486704"></a>
        The name, on Windows systems, of the MySQL
        <span class="bold"><strong>option file</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_my_cnf">my.cnf</a>, <a class="glossseealso" href="glossary.html#glos_option_file">option file</a>.</p></dd><dt><a name="glos_mysql"></a><span class="glossterm">mysql</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395472224"></a>
        The <a class="link" href="programs.html#mysql" title="4.5.1 mysql — The MySQL Command-Line Tool"><span class="command"><strong>mysql</strong></span></a> program is the command-line
        interpreter for the MySQL database. It processes
        <span class="bold"><strong>SQL</strong></span> statements, and also
        MySQL-specific commands such as <a class="link" href="sql-syntax.html#show-tables" title="13.7.6.37 SHOW TABLES Syntax"><code class="literal">SHOW
        TABLES</code></a>, by passing requests to the
        <a class="link" href="programs.html#mysqld" title="4.3.1 mysqld — The MySQL Server"><span class="command"><strong>mysqld</strong></span></a> daemon.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_mysqld">mysqld</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>.</p></dd><dt><a name="glos_mysql_enterprise_backup"></a><span class="glossterm">MySQL Enterprise Backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395464624"></a>
        A licensed product that performs <span class="bold"><strong>hot
        backups</strong></span> of MySQL databases. It offers the most
        efficiency and flexibility when backing up
        <a class="link" href="innodb-storage-engine.html" title="Chapter 15 The InnoDB Storage Engine"><code class="literal">InnoDB</code></a> tables, but can also back up
        <a class="link" href="storage-engines.html#myisam-storage-engine" title="16.2 The MyISAM Storage Engine"><code class="literal">MyISAM</code></a> and other kinds of tables.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>.</p></dd><dt><a name="glos_mysqlbackup_command"></a><span class="glossterm">mysqlbackup command</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395458160"></a>
        A command-line tool of the <span class="bold"><strong>MySQL
        Enterprise Backup</strong></span> product. It performs a
        <span class="bold"><strong>hot backup</strong></span> operation for
        <a class="link" href="innodb-storage-engine.html" title="Chapter 15 The InnoDB Storage Engine"><code class="literal">InnoDB</code></a> tables, and a
        <a class="link" href="glossary.html#glos_warm_backup" title="warm backup">warm backup</a> for
        <a class="link" href="storage-engines.html#myisam-storage-engine" title="16.2 The MyISAM Storage Engine"><code class="literal">MyISAM</code></a> and other kinds of tables.
        See <a class="xref" href="mysql-enterprise.html#mysql-enterprise-backup" title="29.2 MySQL Enterprise Backup Overview">Section 29.2, “MySQL Enterprise Backup Overview”</a> for more
        information about this command.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_warm_backup">warm backup</a>.</p></dd><dt><a name="glos_mysqld"></a><span class="glossterm">mysqld</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395449024"></a>
        The <a class="link" href="programs.html#mysqld" title="4.3.1 mysqld — The MySQL Server"><span class="command"><strong>mysqld</strong></span></a> program is the database engine for
        the MySQL database. It runs as a Unix daemon or Windows service,
        constantly waiting for requests and performing maintenance work
        in the background.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_mysql">mysql</a>.</p></dd><dt><a name="glos_mysqldump"></a><span class="glossterm">mysqldump</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395445008"></a>
        A command that performs a <span class="bold"><strong>logical
        backup</strong></span> of some combination of databases, tables, and
        table data. The results are SQL statements that reproduce the
        original schema objects, data, or both. For substantial amounts
        of data, a <span class="bold"><strong>physical backup</strong></span>
        solution such as <span class="bold"><strong>MySQL Enterprise
        Backup</strong></span> is faster, particularly for the
        <span class="bold"><strong>restore</strong></span> operation.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_logical_backup">logical backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_physical_backup">physical backup</a>, <a class="glossseealso" href="glossary.html#glos_restore">restore</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">N</h3>
<dl><dt><a name="glos_natural_key"></a><span class="glossterm">natural key</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395437136"></a>
        An indexed column, typically a <span class="bold"><strong>primary
        key</strong></span>, where the values have some real-world
        significance. Usually advised against because:
</p>
<div class="itemizedlist">
<ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
            If the value should ever change, there is potentially a lot
            of index maintenance to re-sort the
            <span class="bold"><strong>clustered index</strong></span> and update
            the copies of the primary key value that are repeated in
            each <span class="bold"><strong>secondary index</strong></span>.
          </p></li><li class="listitem"><p>
            Even seemingly stable values can change in unpredictable
            ways that are difficult to represent correctly in the
            database. For example, one country can change into two or
            several, making the original country code obsolete. Or,
            rules about unique values might have exceptions. For
            example, even if taxpayer IDs are intended to be unique to a
            single person, a database might have to handle records that
            violate that rule, such as in cases of identity theft.
            Taxpayer IDs and other sensitive ID numbers also make poor
            primary keys, because they may need to be secured,
            encrypted, and otherwise treated differently than other
            columns.
</p></li></ul>
</div>
<p>
        Thus, it is typically better to use arbitrary numeric values to
        form a <span class="bold"><strong>synthetic key</strong></span>, for
        example using an <span class="bold"><strong>auto-increment</strong></span>
        column.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_auto_increment">auto-increment</a>, <a class="glossseealso" href="glossary.html#glos_clustered_index">clustered index</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>, <a class="glossseealso" href="glossary.html#glos_secondary_index">secondary index</a>, <a class="glossseealso" href="glossary.html#glos_synthetic_key">synthetic key</a>.</p></dd><dt><a name="glos_neighbor_page"></a><span class="glossterm">neighbor page</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395425216"></a>
        Any <span class="bold"><strong>page</strong></span> in the same
        <span class="bold"><strong>extent</strong></span> as a particular page.
        When a page is selected to be
        <span class="bold"><strong>flushed</strong></span>, any neighbor pages
        that are <span class="bold"><strong>dirty</strong></span> are typically
        flushed as well, as an I/O optimization for traditional hard
        disks. In MySQL 5.6 and up, this behavior can be controlled by
        the configuration variable
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_flush_neighbors"><code class="literal">innodb_flush_neighbors</code></a>; you
        might turn that setting off for SSD drives, which do not have
        the same overhead for writing smaller batches of data at random
        locations.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_dirty_page">dirty page</a>, <a class="glossseealso" href="glossary.html#glos_extent">extent</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>.</p></dd><dt><a name="glos_next_key_lock"></a><span class="glossterm">next-key lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395416544"></a>
        A combination of a <span class="bold"><strong>record lock</strong></span>
        on the index record and a <a class="link" href="glossary.html#glos_gap_lock" title="gap lock">gap
        lock</a> on the gap before the index record.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_gap_lock">gap lock</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_record_lock">record lock</a>.</p></dd><dt><a name="glos_non_locking_read"></a><span class="glossterm">non-locking read</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395411312"></a>
        A <span class="bold"><strong>query</strong></span> that does not use the
        <code class="literal">SELECT ... FOR UPDATE</code> or <code class="literal">SELECT ...
        LOCK IN SHARE MODE</code> clauses. The only kind of query
        allowed for global tables in a <span class="bold"><strong>read-only
        transaction</strong></span>. The opposite of a
        <span class="bold"><strong>locking read</strong></span>. See
        <a class="xref" href="innodb-storage-engine.html#innodb-consistent-read" title="15.5.2.3 Consistent Nonlocking Reads">Section 15.5.2.3, “Consistent Nonlocking Reads”</a>.
      </p><p>
        <code class="literal">SELECT ... FOR SHARE</code> replaces <code class="literal">SELECT
        ... LOCK IN SHARE MODE</code> in MySQL 8.0.1, but
        <code class="literal">LOCK IN SHARE MODE</code> remains available for
        backward compatibility.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_locking_read">locking read</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>, <a class="glossseealso" href="glossary.html#glos_read_only_transaction">read-only transaction</a>.</p></dd><dt><a name="glos_non_repeatable_read"></a><span class="glossterm">non-repeatable read</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395400512"></a>
        The situation when a query retrieves data, and a later query
        within the same <span class="bold"><strong>transaction</strong></span>
        retrieves what should be the same data, but the queries return
        different results (changed by another transaction committing in
        the meantime).
      </p><p>
        This kind of operation goes against the
        <span class="bold"><strong>ACID</strong></span> principle of database
        design. Within a transaction, data should be consistent, with
        predictable and stable relationships.
      </p><p>
        Among different <span class="bold"><strong>isolation
        levels</strong></span>, non-repeatable reads are prevented by the
        <span class="bold"><strong>serializable read</strong></span> and
        <span class="bold"><strong>repeatable read</strong></span> levels, and
        allowed by the <span class="bold"><strong>consistent read</strong></span>,
        and <span class="bold"><strong>read uncommitted</strong></span> levels.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_consistent_read">consistent read</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_read_uncommitted">READ UNCOMMITTED</a>, <a class="glossseealso" href="glossary.html#glos_repeatable_read">REPEATABLE READ</a>, <a class="glossseealso" href="glossary.html#glos_serializable">SERIALIZABLE</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_non_blocking_io"></a><span class="glossterm">nonblocking I/O</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395388528"></a>
        An industry term that means the same as
        <span class="bold"><strong>asynchronous I/O</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_asynchronous_io">asynchronous I/O</a>.</p></dd><dt><a name="glos_normalized"></a><span class="glossterm">normalized</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395385232"></a>
        A database design strategy where data is split into multiple
        tables, and duplicate values condensed into single rows
        represented by an ID, to avoid storing, querying, and updating
        redundant or lengthy values. It is typically used in
        <span class="bold"><strong>OLTP</strong></span> applications.
      </p><p>
        For example, an address might be given a unique ID, so that a
        census database could represent the relationship
        <span class="bold"><strong>lives at this address</strong></span> by
        associating that ID with each member of a family, rather than
        storing multiple copies of a complex value such as
        <span class="bold"><strong>123 Main Street, Anytown, USA</strong></span>.
      </p><p>
        For another example, although a simple address book application
        might store each phone number in the same table as a person's
        name and address, a phone company database might give each phone
        number a special ID, and store the numbers and IDs in a separate
        table. This normalized representation could simplify large-scale
        updates when area codes split apart.
      </p><p>
        Normalization is not always recommended. Data that is primarily
        queried, and only updated by deleting entirely and reloading, is
        often kept in fewer, larger tables with redundant copies of
        duplicate values. This data representation is referred to as
        <span class="bold"><strong>denormalized</strong></span>, and is frequently
        found in data warehousing applications.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_denormalized">denormalized</a>, <a class="glossseealso" href="glossary.html#glos_foreign_key">foreign key</a>, <a class="glossseealso" href="glossary.html#glos_oltp">OLTP</a>, <a class="glossseealso" href="glossary.html#glos_relational">relational</a>.</p></dd><dt><a name="glos_nosql"></a><span class="glossterm">NoSQL</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395375712"></a>
        A broad term for a set of data access technologies that do not
        use the <span class="bold"><strong>SQL</strong></span> language as their
        primary mechanism for reading and writing data. Some NoSQL
        technologies act as key-value stores, only accepting
        single-value reads and writes; some relax the restrictions of
        the <span class="bold"><strong>ACID</strong></span> methodology; still
        others do not require a pre-planned
        <span class="bold"><strong>schema</strong></span>. MySQL users can combine
        NoSQL-style processing for speed and simplicity with SQL
        operations for flexibility and convenience, by using the
        <span class="bold"><strong>memcached</strong></span> API to directly
        access some kinds of MySQL tables. The
        <span class="command"><strong>memcached</strong></span> interface to
        <code class="literal">InnoDB</code> tables is available in MySQL 5.6 and
        higher; see <a class="xref" href="innodb-storage-engine.html#innodb-memcached" title="15.19 InnoDB memcached Plugin">Section 15.19, “InnoDB memcached Plugin”</a> for details. The
        <span class="command"><strong>memcached</strong></span> interface to <code class="literal">NDB</code>
        tables is available in NDB Cluster 7.2 and later; see
        <a class="ulink" href="http://dev.mysql.com/doc/ndbapi/en/ndbmemcache.html" target="_top">ndbmemcache—Memcache API for NDB Cluster</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_memcached">memcached</a>, <a class="glossseealso" href="glossary.html#glos_schema">schema</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>.</p></dd><dt><a name="glos_not_null_constraint"></a><span class="glossterm">NOT NULL constraint</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395363136"></a>
        A type of <span class="bold"><strong>constraint</strong></span> that
        specifies that a <span class="bold"><strong>column</strong></span> cannot
        contain any <span class="bold"><strong>NULL</strong></span> values. It
        helps to preserve <span class="bold"><strong>referential
        integrity</strong></span>, as the database server can identify data
        with erroneous missing values. It also helps in the arithmetic
        involved in query optimization, allowing the optimizer to
        predict the number of entries in an index on that column.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_column">column</a>, <a class="glossseealso" href="glossary.html#glos_constraint">constraint</a>, <a class="glossseealso" href="glossary.html#glos_null">NULL</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>, <a class="glossseealso" href="glossary.html#glos_referential_integrity">referential integrity</a>.</p></dd><dt><a name="glos_null"></a><span class="glossterm">NULL</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395355344"></a>
        A special value in <span class="bold"><strong>SQL</strong></span>,
        indicating the absence of data. Any arithmetic operation or
        equality test involving a <code class="literal">NULL</code> value, in turn
        produces a <code class="literal">NULL</code> result. (Thus it is similar
        to the IEEE floating-point concept of NaN, <span class="quote">“<span class="quote">not a
        number</span>”</span>.) Any aggregate calculation such as
        <code class="literal">AVG()</code> ignores rows with
        <code class="literal">NULL</code> values, when determining how many rows
        to divide by. The only test that works with
        <code class="literal">NULL</code> values uses the SQL idioms <code class="literal">IS
        NULL</code> or <code class="literal">IS NOT NULL</code>.
      </p><p>
        <code class="literal">NULL</code> values play a part in
        <span class="bold"><strong>index</strong></span> operations, because for
        performance a database must minimize the overhead of keeping
        track of missing data values. Typically, <code class="literal">NULL</code>
        values are not stored in an index, because a query that tests an
        indexed column using a standard comparison operator could never
        match a row with a <code class="literal">NULL</code> value for that
        column. For the same reason, unique indexes do not prevent
        <code class="literal">NULL</code> values; those values simply are not
        represented in the index. Declaring a <code class="literal">NOT
        NULL</code> constraint on a column provides reassurance that
        there are no rows left out of the index, allowing for better
        query optimization (accurate counting of rows and estimation of
        whether to use the index).
      </p><p>
        Because the <span class="bold"><strong>primary key</strong></span> must be
        able to uniquely identify every row in the table, a
        single-column primary key cannot contain any
        <code class="literal">NULL</code> values, and a multi-column primary key
        cannot contain any rows with <code class="literal">NULL</code> values in
        all columns.
      </p><p>
        Although the Oracle database allows a <code class="literal">NULL</code>
        value to be concatenated with a string,
        <code class="literal">InnoDB</code> treats the result of such an operation
        as <code class="literal">NULL</code>.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">O</h3>
<dl><dt><a name="glos_opt_file"></a><span class="glossterm">.OPT file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395291520"></a>
        A file containing database configuration information. Files with
        this extension are included in backups produced by the
        <span class="command"><strong>mysqlbackup</strong></span> command of the
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_mysqlbackup_command">mysqlbackup command</a>.</p></dd><dt><a name="glos_off_page_column"></a><span class="glossterm">off-page column</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395333920"></a>
        A column containing variable-length data (such as
        <a class="link" href="data-types.html#blob" title="11.4.3 The BLOB and TEXT Types"><code class="literal">BLOB</code></a> and
        <a class="link" href="data-types.html#char" title="11.4.1 The CHAR and VARCHAR Types"><code class="literal">VARCHAR</code></a>) that is too long to fit
        on a <span class="bold"><strong>B-tree</strong></span> page. The data is
        stored in <span class="bold"><strong>overflow pages</strong></span>. The
        <span class="bold"><strong>DYNAMIC</strong></span> row format is more
        efficient for such storage than the older
        <span class="bold"><strong>COMPACT</strong></span> row format.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_b_tree">B-tree</a>, <a class="glossseealso" href="glossary.html#glos_compact_row_format">compact row format</a>, <a class="glossseealso" href="glossary.html#glos_dynamic_row_format">dynamic row format</a>, <a class="glossseealso" href="glossary.html#glos_overflow_page">overflow page</a>.</p></dd><dt><a name="glos_oltp"></a><span class="glossterm">OLTP</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395324304"></a>
        Acronym for <span class="quote">“<span class="quote">Online Transaction Processing</span>”</span>. A
        database system, or a database application, that runs a workload
        with many <span class="bold"><strong>transactions</strong></span>, with
        frequent writes as well as reads, typically affecting small
        amounts of data at a time. For example, an airline reservation
        system or an application that processes bank deposits. The data
        might be organized in
        <span class="bold"><strong>normalized</strong></span> form for a balance
        between <span class="bold"><strong>DML</strong></span>
        (insert/update/delete) efficiency and
        <span class="bold"><strong>query</strong></span> efficiency. Contrast with
        <span class="bold"><strong>data warehouse</strong></span>.
      </p><p>
        With its <span class="bold"><strong>row-level locking</strong></span> and
        <span class="bold"><strong>transactional</strong></span> capability,
        <span class="bold"><strong>InnoDB</strong></span> is the ideal storage
        engine for MySQL tables used in OLTP applications.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_data_warehouse">data warehouse</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>, <a class="glossseealso" href="glossary.html#glos_row_lock">row lock</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_online"></a><span class="glossterm">online</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395312096"></a>
        A type of operation that involves no downtime, blocking, or
        restricted operation for the database. Typically applied to
        <span class="bold"><strong>DDL</strong></span>. Operations that shorten
        the periods of restricted operation, such as
        <span class="bold"><strong>fast index creation</strong></span>, have
        evolved into a wider set of <span class="bold"><strong>online
        DDL</strong></span> operations in MySQL 5.6.
      </p><p>
        In the context of backups, a <span class="bold"><strong>hot
        backup</strong></span> is an online operation and a
        <span class="bold"><strong>warm backup</strong></span> is partially an
        online operation.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_fast_index_creation">Fast Index Creation</a>, <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_online_ddl">online DDL</a>, <a class="glossseealso" href="glossary.html#glos_warm_backup">warm backup</a>.</p></dd><dt><a name="glos_online_ddl"></a><span class="glossterm">online DDL</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395303072"></a>
        A feature that improves the performance, concurrency, and
        availability of <code class="literal">InnoDB</code> tables during
        <span class="bold"><strong>DDL</strong></span> (primarily
        <a class="link" href="sql-syntax.html#alter-table" title="13.1.8 ALTER TABLE Syntax"><code class="literal">ALTER TABLE</code></a>) operations. See
        <a class="xref" href="innodb-storage-engine.html#innodb-online-ddl" title="15.12 InnoDB and Online DDL">Section 15.12, “InnoDB and Online DDL”</a> for details.
      </p><p>
        The details vary according to the type of operation. In some
        cases, the table can be modified concurrently while the
        <a class="link" href="sql-syntax.html#alter-table" title="13.1.8 ALTER TABLE Syntax"><code class="literal">ALTER TABLE</code></a> is in progress. The
        operation might be able to be performed without a table copy, or
        using a specially optimized type of table copy. Space usage is
        controlled by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_online_alter_log_max_size"><code class="literal">innodb_online_alter_log_max_size</code></a>
        configuration option.
      </p><p>
        This feature is an enhancement of the <span class="bold"><strong>Fast
        Index Creation</strong></span> feature in MySQL 5.5.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_fast_index_creation">Fast Index Creation</a>, <a class="glossseealso" href="glossary.html#glos_online">online</a>.</p></dd><dt><a name="glos_optimistic"></a><span class="glossterm">optimistic</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395286496"></a>
        A methodology that guides low-level implementation decisions for
        a relational database system. The requirements of performance
        and <span class="bold"><strong>concurrency</strong></span> in a relational
        database mean that operations must be started or dispatched
        quickly. The requirements of consistency and
        <span class="bold"><strong>referential integrity</strong></span> mean that
        any operation could fail: a transaction might be rolled back, a
        <span class="bold"><strong>DML</strong></span> operation could violate a
        constraint, a request for a lock could cause a deadlock, a
        network error could cause a timeout. An optimistic strategy is
        one that assumes most requests or attempts will succeed, so that
        relatively little work is done to prepare for the failure case.
        When this assumption is true, the database does little
        unnecessary work; when requests do fail, extra work must be done
        to clean up and undo changes.
      </p><p>
        <code class="literal">InnoDB</code> uses optimistic strategies for
        operations such as <span class="bold"><strong>locking</strong></span> and
        <span class="bold"><strong>commits</strong></span>. For example, data
        changed by a transaction can be written to the data files before
        the commit occurs, making the commit itself very fast, but
        requiring more work to undo the changes if the transaction is
        rolled back.
      </p><p>
        The opposite of an optimistic strategy is a
        <span class="bold"><strong>pessimistic</strong></span> one, where a system
        is optimized to deal with operations that are unreliable and
        frequently unsuccessful. This methodology is rare in a database
        system, because so much care goes into choosing reliable
        hardware, networks, and algorithms.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_pessimistic">pessimistic</a>, <a class="glossseealso" href="glossary.html#glos_referential_integrity">referential integrity</a>.</p></dd><dt><a name="glos_optimizer"></a><span class="glossterm">optimizer</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395274144"></a>
        The MySQL component that determines the best
        <span class="bold"><strong>indexes</strong></span> and
        <span class="bold"><strong>join</strong></span> order to use for a
        <span class="bold"><strong>query</strong></span>, based on characteristics
        and data distribution of the relevant
        <span class="bold"><strong>tables</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_join">join</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_option"></a><span class="glossterm">option</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395267120"></a>
        A configuration parameter for MySQL, either stored in the
        <span class="bold"><strong>option file</strong></span> or passed on the
        command line.
      </p><p>
        For the <span class="bold"><strong>options</strong></span> that apply to
        <span class="bold"><strong>InnoDB</strong></span> tables, each option name
        starts with the prefix <code class="literal">innodb_</code>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_option">option</a>, <a class="glossseealso" href="glossary.html#glos_option_file">option file</a>.</p></dd><dt><a name="glos_option_file"></a><span class="glossterm">option file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395260064"></a>
        The file that holds the configuration
        <span class="bold"><strong>options</strong></span> for the MySQL instance.
        Traditionally, on Linux and Unix this file is named
        <code class="literal">my.cnf</code>, and on Windows it is named
        <code class="literal">my.ini</code>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_configuration_file">configuration file</a>, <a class="glossseealso" href="glossary.html#glos_my_cnf">my.cnf</a>, <a class="glossseealso" href="glossary.html#glos_my_ini">my.ini</a>, <a class="glossseealso" href="glossary.html#glos_option">option</a>.</p></dd><dt><a name="glos_overflow_page"></a><span class="glossterm">overflow page</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395253712"></a>
        Separately allocated disk <span class="bold"><strong>pages</strong></span>
        that hold variable-length columns (such as
        <code class="literal">BLOB</code> and <code class="literal">VARCHAR</code>) that are
        too long to fit on a <span class="bold"><strong>B-tree</strong></span>
        page. The associated columns are known as
        <span class="bold"><strong>off-page columns</strong></span>.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_b_tree">B-tree</a>, <a class="glossseealso" href="glossary.html#glos_off_page_column">off-page column</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">P</h3>
<dl><dt><a name="glos_par_file"></a><span class="glossterm">.par file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395199808"></a>
        A file containing partition definitions. Files with this
        extension are included in backups produced by the
        <code class="literal">mysqlbackup</code> command of the
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product.
      </p><p>
        With the introduction of native partitioning support for
        <code class="literal">InnoDB</code> tables in MySQL 5.7.6,
        <code class="filename">.par</code> files are no longer created for
        partitioned <code class="literal">InnoDB</code> tables. Partitioned
        <code class="literal">MyISAM</code> tables continue to use
        <code class="filename">.par</code> files in MySQL 5.7. In MySQL 8.0,
        partitioning support is only provided by the
        <code class="literal">InnoDB</code> storage engine. As such,
        <code class="filename">.par</code> files are no longer used as of MySQL
        8.0.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_mysqlbackup_command">mysqlbackup command</a>.</p></dd><dt><a name="glos_page"></a><span class="glossterm">page</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395245904"></a>
        A unit representing how much data <code class="literal">InnoDB</code>
        transfers at any one time between disk (the
        <span class="bold"><strong>data files</strong></span>) and memory (the
        <span class="bold"><strong>buffer pool</strong></span>). A page can
        contain one or more <span class="bold"><strong>rows</strong></span>,
        depending on how much data is in each row. If a row does not fit
        entirely into a single page, <code class="literal">InnoDB</code> sets up
        additional pointer-style data structures so that the information
        about the row can be stored in one page.
      </p><p>
        One way to fit more data in each page is to use
        <span class="bold"><strong>compressed row format</strong></span>. For
        tables that use BLOBs or large text fields,
        <span class="bold"><strong>compact row format</strong></span> allows those
        large columns to be stored separately from the rest of the row,
        reducing I/O overhead and memory usage for queries that do not
        reference those columns.
      </p><p>
        When <code class="literal">InnoDB</code> reads or writes sets of pages as
        a batch to increase I/O throughput, it reads or writes an
        <span class="bold"><strong>extent</strong></span> at a time.
      </p><p>
        All the <code class="literal">InnoDB</code> disk data structures within a
        MySQL instance share the same <span class="bold"><strong>page
        size</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_compact_row_format">compact row format</a>, <a class="glossseealso" href="glossary.html#glos_compressed_row_format">compressed row format</a>, <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_extent">extent</a>, <a class="glossseealso" href="glossary.html#glos_page_size">page size</a>, <a class="glossseealso" href="glossary.html#glos_row">row</a>.</p></dd><dt><a name="glos_page_cleaner"></a><span class="glossterm">page cleaner</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395230336"></a>
        An <code class="literal">InnoDB</code> background
        <span class="bold"><strong>thread</strong></span> that
        <span class="bold"><strong>flushes</strong></span>
        <span class="bold"><strong>dirty pages</strong></span> from the
        <span class="bold"><strong>buffer pool</strong></span>. Prior to MySQL
        5.6, this activity was performed by the
        <span class="bold"><strong>master thread</strong></span>. The number of
        page cleaner threads is controlled by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_page_cleaners"><code class="literal">innodb_page_cleaners</code></a>
        configuration option, introduced in MySQL 5.7.4.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_dirty_page">dirty page</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_master_thread">master thread</a>, <a class="glossseealso" href="glossary.html#glos_thread">thread</a>.</p></dd><dt><a name="glos_page_size"></a><span class="glossterm">page size</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395219968"></a>
        For releases up to and including MySQL 5.5, the size of each
        <code class="literal">InnoDB</code> <span class="bold"><strong>page</strong></span>
        is fixed at 16 kilobytes. This value represents a balance: large
        enough to hold the data for most rows, yet small enough to
        minimize the performance overhead of transferring unneeded data
        to memory. Other values are not tested or supported.
      </p><p>
        Starting in MySQL 5.6, the page size for an
        <code class="literal">InnoDB</code>
        <span class="bold"><strong>instance</strong></span> can be either 4KB,
        8KB, or 16KB, controlled by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_page_size"><code class="literal">innodb_page_size</code></a> configuration
        option. As of MySQL 5.7.6, <code class="literal">InnoDB</code> also
        supports 32KB and 64KB page sizes. For 32KB and 64KB page sizes,
        <code class="literal">ROW_FORMAT=COMPRESSED</code> is not supported and
        the maximum record size is 16KB.
      </p><p>
        Page size is set when creating the MySQL instance, and it
        remains constant afterward. The same page size applies to all
        <code class="literal">InnoDB</code>
        <span class="bold"><strong>tablespaces</strong></span>, including the
        <span class="bold"><strong>system tablespace</strong></span>,
        <span class="bold"><strong>file-per-table</strong></span> tablespaces, and
        <span class="bold"><strong>general tablespaces</strong></span>.
      </p><p>
        Smaller page sizes can help performance with storage devices
        that use small block sizes, particularly for
        <span class="bold"><strong>SSD</strong></span> devices in
        <span class="bold"><strong>disk-bound</strong></span> workloads, such as
        for <span class="bold"><strong>OLTP</strong></span> applications. As
        individual rows are updated, less data is copied into memory,
        written to disk, reorganized, locked, and so on.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_disk_bound">disk-bound</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_general_tablespace">general tablespace</a>, <a class="glossseealso" href="glossary.html#glos_instance">instance</a>, <a class="glossseealso" href="glossary.html#glos_oltp">OLTP</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_ssd">SSD</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>.</p></dd><dt><a name="glos_parent_table"></a><span class="glossterm">parent table</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395188992"></a>
        The table in a <span class="bold"><strong>foreign key</strong></span>
        relationship that holds the initial column values pointed to
        from the <span class="bold"><strong>child table</strong></span>. The
        consequences of deleting, or updating rows in the parent table
        depend on the <code class="literal">ON UPDATE</code> and <code class="literal">ON
        DELETE</code> clauses in the foreign key definition. Rows
        with corresponding values in the child table could be
        automatically deleted or updated in turn, or those columns could
        be set to <code class="literal">NULL</code>, or the operation could be
        prevented.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_child_table">child table</a>, <a class="glossseealso" href="glossary.html#glos_foreign_key">foreign key</a>.</p></dd><dt><a name="glos_partial_backup"></a><span class="glossterm">partial backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395182032"></a>
        A <span class="bold"><strong>backup</strong></span> that contains some of
        the <span class="bold"><strong>tables</strong></span> in a MySQL database,
        or some of the databases in a MySQL instance. Contrast with
        <span class="bold"><strong>full backup</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_backup">backup</a>, <a class="glossseealso" href="glossary.html#glos_full_backup">full backup</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_partial_index"></a><span class="glossterm">partial index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395176096"></a>
        An <span class="bold"><strong>index</strong></span> that represents only
        part of a column value, typically the first N characters (the
        <span class="bold"><strong>prefix</strong></span>) of a long
        <code class="literal">VARCHAR</code> value.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_index_prefix">index prefix</a>.</p></dd><dt><a name="glos_performance_schema"></a><span class="glossterm">Performance Schema</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395170752"></a>
        The <code class="literal">performance_schema</code> schema, in MySQL 5.5
        and up, presents a set of tables that you can query to get
        detailed information about the performance characteristics of
        many internal parts of the MySQL server. See
        <a class="xref" href="performance-schema.html" title="Chapter 25 MySQL Performance Schema">Chapter 25, <i>MySQL Performance Schema</i></a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_information_schema">INFORMATION_SCHEMA</a>, <a class="glossseealso" href="glossary.html#glos_latch">latch</a>, <a class="glossseealso" href="glossary.html#glos_mutex">mutex</a>, <a class="glossseealso" href="glossary.html#glos_rw_lock">rw-lock</a>.</p></dd><dt><a name="glos_persistent_statistics"></a><span class="glossterm">persistent statistics</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395164944"></a>
        A feature in MySQL 5.6 that stores
        <span class="bold"><strong>index</strong></span> statistics for
        <code class="literal">InnoDB</code>
        <span class="bold"><strong>tables</strong></span> on disk, providing
        better <span class="bold"><strong>plan stability</strong></span> for
        <span class="bold"><strong>queries</strong></span>. For more information,
        see <a class="xref" href="innodb-storage-engine.html#innodb-persistent-stats" title="15.6.11.1 Configuring Persistent Optimizer Statistics Parameters">Section 15.6.11.1, “Configuring Persistent Optimizer Statistics Parameters”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_optimizer">optimizer</a>, <a class="glossseealso" href="glossary.html#glos_plan_stability">plan stability</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_pessimistic"></a><span class="glossterm">pessimistic</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395156032"></a>
        A methodology that sacrifices performance or concurrency in
        favor of safety. It is appropriate if a high proportion of
        requests or attempts might fail, or if the consequences of a
        failed request are severe. <code class="literal">InnoDB</code> uses what
        is known as a pessimistic
        <span class="bold"><strong>locking</strong></span> strategy, to minimize
        the chance of <span class="bold"><strong>deadlocks</strong></span>. At the
        application level, you might avoid deadlocks by using a
        pessimistic strategy of acquiring all locks needed by a
        transaction at the very beginning.
      </p><p>
        Many built-in database mechanisms use the opposite
        <span class="bold"><strong>optimistic</strong></span> methodology.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_deadlock">deadlock</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_optimistic">optimistic</a>.</p></dd><dt><a name="glos_phantom"></a><span class="glossterm">phantom</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395148560"></a>
        A row that appears in the result set of a query, but not in the
        result set of an earlier query. For example, if a query is run
        twice within a <span class="bold"><strong>transaction</strong></span>, and
        in the meantime, another transaction commits after inserting a
        new row or updating a row so that it matches the
        <code class="literal">WHERE</code> clause of the query.
      </p><p>
        This occurrence is known as a phantom read. It is harder to
        guard against than a <span class="bold"><strong>non-repeatable
        read</strong></span>, because locking all the rows from the first
        query result set does not prevent the changes that cause the
        phantom to appear.
      </p><p>
        Among different <span class="bold"><strong>isolation
        levels</strong></span>, phantom reads are prevented by the
        <span class="bold"><strong>serializable read</strong></span> level, and
        allowed by the <span class="bold"><strong>repeatable read</strong></span>,
        <span class="bold"><strong>consistent read</strong></span>, and
        <span class="bold"><strong>read uncommitted</strong></span> levels.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_consistent_read">consistent read</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_non_repeatable_read">non-repeatable read</a>, <a class="glossseealso" href="glossary.html#glos_read_uncommitted">READ UNCOMMITTED</a>, <a class="glossseealso" href="glossary.html#glos_repeatable_read">REPEATABLE READ</a>, <a class="glossseealso" href="glossary.html#glos_serializable">SERIALIZABLE</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_physical"></a><span class="glossterm">physical</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395135680"></a>
        A type of operation that involves hardware-related aspects such
        as disk blocks, memory pages, files, bits, disk reads, and so
        on. Typically, physical aspects are important during
        expert-level performance tuning and problem diagnosis. Contrast
        with <span class="bold"><strong>logical</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_logical">logical</a>, <a class="glossseealso" href="glossary.html#glos_physical_backup">physical backup</a>.</p></dd><dt><a name="glos_physical_backup"></a><span class="glossterm">physical backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395131584"></a>
        A <span class="bold"><strong>backup</strong></span> that copies the actual
        data files. For example, the
        <span class="bold"><strong><code class="literal">mysqlbackup</code></strong></span>
        command of the <span class="bold"><strong>MySQL Enterprise
        Backup</strong></span> product produces a physical backup, because
        its output contains data files that can be used directly by the
        <code class="literal">mysqld</code> server, resulting in a faster
        <span class="bold"><strong>restore</strong></span> operation. Contrast
        with <span class="bold"><strong>logical backup</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_backup">backup</a>, <a class="glossseealso" href="glossary.html#glos_logical_backup">logical backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_restore">restore</a>.</p></dd><dt><a name="glos_pitr"></a><span class="glossterm">PITR</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395122432"></a>
        Acronym for <span class="bold"><strong>point-in-time
        recovery</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_point_in_time_recovery">point-in-time recovery</a>.</p></dd><dt><a name="glos_plan_stability"></a><span class="glossterm">plan stability</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395118848"></a>
        A property of a <span class="bold"><strong>query execution
        plan</strong></span>, where the optimizer makes the same choices each
        time for a given <span class="bold"><strong>query</strong></span>, so that
        performance is consistent and predictable.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_query">query</a>, <a class="glossseealso" href="glossary.html#glos_query_execution_plan">query execution plan</a>.</p></dd><dt><a name="glos_point_in_time_recovery"></a><span class="glossterm">point-in-time recovery</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395114160"></a>
        The process of restoring a
        <span class="bold"><strong>backup</strong></span> to recreate the state of
        the database at a specific date and time. Commonly abbreviated
        <span class="quote">“<span class="quote">PITR</span>”</span>. Because it is unlikely that the specified
        time corresponds exactly to the time of a backup, this technique
        usually requires a combination of a
        <span class="bold"><strong>physical backup</strong></span> and a
        <span class="bold"><strong>logical backup</strong></span>. For example,
        with the <span class="bold"><strong>MySQL Enterprise
        Backup</strong></span> product, you restore the last backup that you
        took before the specified point in time, then replay changes
        from the <span class="bold"><strong>binary log</strong></span> between the
        time of the backup and the PITR time.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_backup">backup</a>, <a class="glossseealso" href="glossary.html#glos_binary_log">binary log</a>, <a class="glossseealso" href="glossary.html#glos_logical_backup">logical backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_physical_backup">physical backup</a>.</p></dd><dt><a name="glos_prefix"></a><span class="glossterm">prefix</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_index_prefix">index prefix</a>.</p></dd><dt><a name="glos_prepared_backup"></a><span class="glossterm">prepared backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395103584"></a>
        A set of backup files, produced by the
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product, after all the stages of applying
        <span class="bold"><strong>binary logs</strong></span> and
        <span class="bold"><strong>incremental backups</strong></span> are
        finished. The resulting files are ready to be
        <span class="bold"><strong>restored</strong></span>. Prior to the apply
        steps, the files are known as a <span class="bold"><strong>raw
        backup</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_binary_log">binary log</a>, <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_incremental_backup">incremental backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_raw_backup">raw backup</a>, <a class="glossseealso" href="glossary.html#glos_restore">restore</a>.</p></dd><dt><a name="glos_primary_key"></a><span class="glossterm">primary key</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395094608"></a>
        A set of columns—and by implication, the index based on
        this set of columns—that can uniquely identify every row
        in a table. As such, it must be a unique index that does not
        contain any <code class="literal">NULL</code> values.
      </p><p>
        <code class="literal">InnoDB</code> requires that every table has such an
        index (also called the <span class="bold"><strong>clustered
        index</strong></span> or <span class="bold"><strong>cluster
        index</strong></span>), and organizes the table storage based on the
        column values of the primary key.
      </p><p>
        When choosing primary key values, consider using arbitrary
        values (a <span class="bold"><strong>synthetic key</strong></span>) rather
        than relying on values derived from some other source (a
        <span class="bold"><strong>natural key</strong></span>).
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_clustered_index">clustered index</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_natural_key">natural key</a>, <a class="glossseealso" href="glossary.html#glos_synthetic_key">synthetic key</a>.</p></dd><dt><a name="glos_process"></a><span class="glossterm">process</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395084624"></a>
        An instance of an executing program. The operating system
        switches between multiple running processes, allowing for a
        certain degree of <span class="bold"><strong>concurrency</strong></span>.
        On most operating systems, processes can contain multiple
        <span class="bold"><strong>threads</strong></span> of execution that share
        resources. Context-switching between threads is faster than the
        equivalent switching between processes.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_thread">thread</a>.</p></dd><dt><a name="glos_pseudo_record"></a><span class="glossterm">pseudo-record</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395079744"></a>
        An artificial record in an index, used for
        <span class="bold"><strong>locking</strong></span> key values or ranges
        that do not currently exist.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_infimum_record">infimum record</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_supremum_record">supremum record</a>.</p></dd><dt><a name="glos_pthreads"></a><span class="glossterm">Pthreads</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395075312"></a>
        The POSIX threads standard, which defines an API for threading
        and locking operations on Unix and Linux systems. On Unix and
        Linux systems, <code class="literal">InnoDB</code> uses this
        implementation for <span class="bold"><strong>mutexes</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_mutex">mutex</a>.</p></dd><dt><a name="glos_purge"></a><span class="glossterm">purge</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395071184"></a>
        A type of garbage collection performed by one or more separate
        background threads (controlled by
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_purge_threads"><code class="literal">innodb_purge_threads</code></a>) that runs
        on a periodic schedule. Purge parses and processes
        <span class="bold"><strong>undo log</strong></span> pages from the
        <span class="bold"><strong>history list</strong></span> for the purpose of
        removing clustered and secondary index records that were marked
        for deletion (by previous <a class="link" href="sql-syntax.html#delete" title="13.2.2 DELETE Syntax"><code class="literal">DELETE</code></a>
        statements) and are no longer required for
        <span class="bold"><strong>MVCC</strong></span> or
        <span class="bold"><strong>rollback</strong></span>. Purge frees undo log
        pages from the history list after processing them.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_history_list">history list</a>, <a class="glossseealso" href="glossary.html#glos_mvcc">MVCC</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>.</p></dd><dt><a name="glos_purge_buffering"></a><span class="glossterm">purge buffering</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395061312"></a>
        The technique of storing changes to secondary index pages,
        resulting from <code class="literal">DELETE</code> operations, in the
        <span class="bold"><strong>change buffer</strong></span> rather than
        writing the changes immediately, so that the physical writes can
        be performed to minimize random I/O. (Because delete operations
        are a two-step process, this operation buffers the write that
        normally purges an index record that was previously marked for
        deletion.) It is one of the types of
        <span class="bold"><strong>change buffering</strong></span>; the others
        are <span class="bold"><strong>insert buffering</strong></span> and
        <span class="bold"><strong>delete buffering</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_change_buffer">change buffer</a>, <a class="glossseealso" href="glossary.html#glos_change_buffering">change buffering</a>, <a class="glossseealso" href="glossary.html#glos_delete_buffering">delete buffering</a>, <a class="glossseealso" href="glossary.html#glos_insert_buffer">insert buffer</a>, <a class="glossseealso" href="glossary.html#glos_insert_buffering">insert buffering</a>.</p></dd><dt><a name="glos_purge_lag"></a><span class="glossterm">purge lag</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395052688"></a>
        Another name for the <code class="literal">InnoDB</code>
        <span class="bold"><strong>history list</strong></span>. Related to the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_max_purge_lag"><code class="literal">innodb_max_purge_lag</code></a>
        configuration option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_history_list">history list</a>, <a class="glossseealso" href="glossary.html#glos_purge">purge</a>.</p></dd><dt><a name="glos_purge_thread"></a><span class="glossterm">purge thread</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395046864"></a>
        A <span class="bold"><strong>thread</strong></span> within the
        <code class="literal">InnoDB</code> process that is dedicated to
        performing the periodic <span class="bold"><strong>purge</strong></span>
        operation. In MySQL 5.6 and higher, multiple purge threads are
        enabled by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_purge_threads"><code class="literal">innodb_purge_threads</code></a>
        configuration option.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_purge">purge</a>, <a class="glossseealso" href="glossary.html#glos_thread">thread</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">Q</h3>
<dl><dt><a name="glos_query"></a><span class="glossterm">query</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395039680"></a>
        In <span class="bold"><strong>SQL</strong></span>, an operation that reads
        information from one or more
        <span class="bold"><strong>tables</strong></span>. Depending on the
        organization of data and the parameters of the query, the lookup
        might be optimized by consulting an
        <span class="bold"><strong>index</strong></span>. If multiple tables are
        involved, the query is known as a
        <span class="bold"><strong>join</strong></span>.
      </p><p>
        For historical reasons, sometimes discussions of internal
        processing for statements use <span class="quote">“<span class="quote">query</span>”</span> in a broader
        sense, including other types of MySQL statements such as
        <span class="bold"><strong>DDL</strong></span> and
        <span class="bold"><strong>DML</strong></span> statements.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_join">join</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_query_execution_plan"></a><span class="glossterm">query execution plan</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395028960"></a>
        The set of decisions made by the optimizer about how to perform
        a <span class="bold"><strong>query</strong></span> most efficiently,
        including which <span class="bold"><strong>index</strong></span> or
        indexes to use, and the order in which to
        <span class="bold"><strong>join</strong></span> tables.
        <span class="bold"><strong>Plan stability</strong></span> involves the
        same choices being made consistently for a given query.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_join">join</a>, <a class="glossseealso" href="glossary.html#glos_plan_stability">plan stability</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>.</p></dd><dt><a name="glos_query_log"></a><span class="glossterm">query log</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_general_query_log">general query log</a>.</p></dd><dt><a name="glos_quiesce"></a><span class="glossterm">quiesce</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395020400"></a>
        To reduce the amount of database activity, often in preparation
        for an operation such as an <a class="link" href="sql-syntax.html#alter-table" title="13.1.8 ALTER TABLE Syntax"><code class="literal">ALTER
        TABLE</code></a>, a <span class="bold"><strong>backup</strong></span>, or a
        <span class="bold"><strong>shutdown</strong></span>. Might or might not
        involve doing as much <span class="bold"><strong>flushing</strong></span>
        as possible, so that <span class="bold"><strong>InnoDB</strong></span>
        does not continue doing background I/O.
      </p><p>
        In MySQL 5.6 and higher, the syntax <code class="literal">FLUSH TABLES ...
        FOR EXPORT</code> writes some data to disk for
        <code class="literal">InnoDB</code> tables that make it simpler to back up
        those tables by copying the data files.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_backup">backup</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_shutdown">shutdown</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">R</h3>
<dl><dt><a name="glos_r_tree"></a><span class="glossterm">R-tree</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395009536"></a>
        A tree data structure used for spatial indexing of
        multi-dimensional data such as geographical coordinates,
        rectangles or polygons.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_b_tree">B-tree</a>.</p></dd><dt><a name="glos_raid"></a><span class="glossterm">RAID</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395006752"></a>
        Acronym for <span class="quote">“<span class="quote">Redundant Array of Inexpensive
        Drives</span>”</span>. Spreading I/O operations across multiple drives
        enables greater <span class="bold"><strong>concurrency</strong></span> at
        the hardware level, and improves the efficiency of low-level
        write operations that otherwise would be performed in sequence.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>.</p></dd><dt><a name="glos_random_dive"></a><span class="glossterm">random dive</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899395002832"></a>
        A technique for quickly estimating the number of different
        values in a column (the column's
        <span class="bold"><strong>cardinality</strong></span>).
        <code class="literal">InnoDB</code> samples pages at random from the index
        and uses that data to estimate the number of different values.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_cardinality">cardinality</a>.</p></dd><dt><a name="glos_raw_backup"></a><span class="glossterm">raw backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394998672"></a>
        The initial set of backup files produced by the
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product, before the changes reflected in the
        <span class="bold"><strong>binary log</strong></span> and any
        <span class="bold"><strong>incremental backups</strong></span> are
        applied. At this stage, the files are not ready to
        <span class="bold"><strong>restore</strong></span>. After these changes
        are applied, the files are known as a
        <span class="bold"><strong>prepared backup</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_binary_log">binary log</a>, <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_ibbackup_logfile">ibbackup_logfile</a>, <a class="glossseealso" href="glossary.html#glos_incremental_backup">incremental backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_prepared_backup">prepared backup</a>, <a class="glossseealso" href="glossary.html#glos_restore">restore</a>.</p></dd><dt><a name="glos_read_committed"></a><span class="glossterm">READ COMMITTED</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394989216"></a>
        An <span class="bold"><strong>isolation level</strong></span> that uses a
        <span class="bold"><strong>locking</strong></span> strategy that relaxes
        some of the protection between
        <span class="bold"><strong>transactions</strong></span>, in the interest
        of performance. Transactions cannot see uncommitted data from
        other transactions, but they can see data that is committed by
        another transaction after the current transaction started. Thus,
        a transaction never sees any bad data, but the data that it does
        see may depend to some extent on the timing of other
        transactions.
      </p><p>
        When a transaction with this isolation level performs
        <code class="literal">UPDATE ... WHERE</code> or <code class="literal">DELETE ...
        WHERE</code> operations, other transactions might have to
        wait. The transaction can perform <code class="literal">SELECT ... FOR
        UPDATE</code>, and <code class="literal">LOCK IN SHARE MODE</code>
        operations without making other transactions wait.
      </p><p>
        <code class="literal">SELECT ... FOR SHARE</code> replaces <code class="literal">SELECT
        ... LOCK IN SHARE MODE</code> in MySQL 8.0.1, but
        <code class="literal">LOCK IN SHARE MODE</code> remains available for
        backward compatibility.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_repeatable_read">REPEATABLE READ</a>, <a class="glossseealso" href="glossary.html#glos_serializable">SERIALIZABLE</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_read_phenomena"></a><span class="glossterm">read phenomena</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394975360"></a>
        Phenomena such as <span class="bold"><strong>dirty reads</strong></span>,
        <span class="bold"><strong>non-repeatable reads</strong></span>, and
        <span class="bold"><strong>phantom</strong></span> reads which can occur
        when a transaction reads data that another transaction has
        modified.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_dirty_read">dirty read</a>, <a class="glossseealso" href="glossary.html#glos_non_repeatable_read">non-repeatable read</a>, <a class="glossseealso" href="glossary.html#glos_phantom">phantom</a>.</p></dd><dt><a name="glos_read_uncommitted"></a><span class="glossterm">READ UNCOMMITTED</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394969440"></a>
        The <span class="bold"><strong>isolation level</strong></span> that
        provides the least amount of protection between transactions.
        Queries employ a <span class="bold"><strong>locking</strong></span>
        strategy that allows them to proceed in situations where they
        would normally wait for another transaction. However, this extra
        performance comes at the cost of less reliable results,
        including data that has been changed by other transactions and
        not committed yet (known as <span class="bold"><strong>dirty
        read</strong></span>). Use this isolation level with great caution,
        and be aware that the results might not be consistent or
        reproducible, depending on what other transactions are doing at
        the same time. Typically, transactions with this isolation level
        only do queries, not insert, update, or delete operations.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_dirty_read">dirty read</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_read_view"></a><span class="glossterm">read view</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394961936"></a>
        An internal snapshot used by the
        <span class="bold"><strong>MVCC</strong></span> mechanism of
        <code class="literal">InnoDB</code>. Certain
        <span class="bold"><strong>transactions</strong></span>, depending on
        their <span class="bold"><strong>isolation level</strong></span>, see the
        data values as they were at the time the transaction (or in some
        cases, the statement) started. Isolation levels that use a read
        view are <span class="bold"><strong>REPEATABLE READ</strong></span>,
        <span class="bold"><strong>READ COMMITTED</strong></span>, and
        <span class="bold"><strong>READ UNCOMMITTED</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_mvcc">MVCC</a>, <a class="glossseealso" href="glossary.html#glos_read_committed">READ COMMITTED</a>, <a class="glossseealso" href="glossary.html#glos_read_uncommitted">READ UNCOMMITTED</a>, <a class="glossseealso" href="glossary.html#glos_repeatable_read">REPEATABLE READ</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_read_ahead"></a><span class="glossterm">read-ahead</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394951600"></a>
        A type of I/O request that prefetches a group of
        <span class="bold"><strong>pages</strong></span> (an entire
        <span class="bold"><strong>extent</strong></span>) into the
        <span class="bold"><strong>buffer pool</strong></span> asynchronously, in
        anticipation that these pages will be needed soon. The linear
        read-ahead technique prefetches all the pages of one extent
        based on access patterns for pages in the preceding extent. The
        random read-ahead technique prefetches all the pages for an
        extent once a certain number of pages from the same extent are
        in the buffer pool. Random read-ahead is not part of MySQL 5.5,
        but is re-introduced in MySQL 5.6 under the control of the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_random_read_ahead"><code class="literal">innodb_random_read_ahead</code></a>
        configuration option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_extent">extent</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>.</p></dd><dt><a name="glos_read_only_transaction"></a><span class="glossterm">read-only transaction</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394943968"></a>
        A type of <span class="bold"><strong>transaction</strong></span> that can
        be optimized for <code class="literal">InnoDB</code> tables by eliminating
        some of the bookkeeping involved with creating a
        <span class="bold"><strong>read view</strong></span> for each transaction.
        Can only perform <span class="bold"><strong>non-locking
        read</strong></span> queries. It can be started explicitly with the
        syntax <a class="link" href="sql-syntax.html#commit" title="13.3.1 START TRANSACTION, COMMIT, and ROLLBACK Syntax"><code class="literal">START TRANSACTION
        READ ONLY</code></a>, or automatically under certain conditions.
        See <a class="xref" href="optimization.html#innodb-performance-ro-txn" title="8.5.3 Optimizing InnoDB Read-Only Transactions">Section 8.5.3, “Optimizing InnoDB Read-Only Transactions”</a> for details.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_non_locking_read">non-locking read</a>, <a class="glossseealso" href="glossary.html#glos_read_view">read view</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_record_lock"></a><span class="glossterm">record lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394935328"></a>
        A <a class="link" href="glossary.html#glos_lock" title="lock">lock</a> on an index record. For
        example, <code class="literal">SELECT c1 FROM t WHERE c1 = 10 FOR
        UPDATE;</code> prevents any other transaction from inserting,
        updating, or deleting rows where the value of
        <code class="literal">t.c1</code> is 10. Contrast with
        <span class="bold"><strong>gap lock</strong></span> and
        <span class="bold"><strong>next-key lock</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_gap_lock">gap lock</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_next_key_lock">next-key lock</a>.</p></dd><dt><a name="glos_redo"></a><span class="glossterm">redo</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394927840"></a>
        The data, in units of records, recorded in the
        <span class="bold"><strong>redo log</strong></span> when
        <a class="link" href="glossary.html#glos_dml" title="DML">DML</a> statements make changes to
        <code class="literal">InnoDB</code> tables. It is used during
        <span class="bold"><strong>crash recovery</strong></span> to correct data
        written by incomplete
        <span class="bold"><strong>transactions</strong></span>. The
        ever-increasing <span class="bold"><strong>LSN</strong></span> value
        represents the cumulative amount of redo data that has passed
        through the redo log.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_crash_recovery">crash recovery</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_lsn">LSN</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_redo_log"></a><span class="glossterm">redo log</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394918608"></a>
        A disk-based data structure used during
        <span class="bold"><strong>crash recovery</strong></span>, to correct data
        written by incomplete
        <span class="bold"><strong>transactions</strong></span>. During normal
        operation, it encodes requests to change
        <code class="literal">InnoDB</code> table data, which result from SQL
        statements or low-level API calls through NoSQL interfaces.
        Modifications that did not finish updating the
        <span class="bold"><strong>data files</strong></span> before an unexpected
        <span class="bold"><strong>shutdown</strong></span> are replayed
        automatically.
      </p><p>
        The redo log is physically represented as a set of files,
        typically named <code class="filename">ib_logfile0</code> and
        <code class="filename">ib_logfile1</code>. The data in the redo log is
        encoded in terms of records affected; this data is collectively
        referred to as <span class="bold"><strong>redo</strong></span>. The
        passage of data through the redo logs is represented by the
        ever-increasing <span class="bold"><strong>LSN</strong></span> value. The
        original 4GB limit on maximum size for the redo log is raised to
        512GB in MySQL 5.6.3.
      </p><p>
        The disk layout of the redo log is influenced by the
        configuration options
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_log_file_size"><code class="literal">innodb_log_file_size</code></a>,
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_log_group_home_dir"><code class="literal">innodb_log_group_home_dir</code></a>, and
        (rarely)
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_log_files_in_group"><code class="literal">innodb_log_files_in_group</code></a>. The
        performance of redo log operations is also affected by the
        <span class="bold"><strong>log buffer</strong></span>, which is controlled
        by the <a class="link" href="innodb-storage-engine.html#sysvar_innodb_log_buffer_size"><code class="literal">innodb_log_buffer_size</code></a>
        configuration option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_crash_recovery">crash recovery</a>, <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_ib_logfile">ib_logfile</a>, <a class="glossseealso" href="glossary.html#glos_log_buffer">log buffer</a>, <a class="glossseealso" href="glossary.html#glos_lsn">LSN</a>, <a class="glossseealso" href="glossary.html#glos_redo">redo</a>, <a class="glossseealso" href="glossary.html#glos_shutdown">shutdown</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_redundant_row_format"></a><span class="glossterm">redundant row format</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394898208"></a>
        The oldest <code class="literal">InnoDB</code> <span class="bold"><strong>row
        format</strong></span>. Prior to MySQL 5.0.3, it was the only row
        format available in <code class="literal">InnoDB</code>. From MySQL 5.0.3
        to MySQL 5.7.8, the default row format is
        <span class="bold"><strong>COMPACT</strong></span>. As of MySQL 5.7.9, the
        default row format is defined by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_default_row_format"><code class="literal">innodb_default_row_format</code></a>
        configuration option, which has a default setting of
        <span class="bold"><strong>DYNAMIC</strong></span>. You can still specify
        the <span class="bold"><strong>REDUNDANT</strong></span> row format for
        compatibility with older <code class="literal">InnoDB</code> tables.
      </p><p>
        For more information, see
        <a class="xref" href="innodb-storage-engine.html#innodb-row-format-antelope" title="15.10.4 COMPACT and REDUNDANT Row Formats">Section 15.10.4, “COMPACT and REDUNDANT Row Formats”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_compact_row_format">compact row format</a>, <a class="glossseealso" href="glossary.html#glos_dynamic_row_format">dynamic row format</a>, <a class="glossseealso" href="glossary.html#glos_row_format">row format</a>.</p></dd><dt><a name="glos_referential_integrity"></a><span class="glossterm">referential integrity</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394886896"></a>
        The technique of maintaining data always in a consistent format,
        part of the <span class="bold"><strong>ACID</strong></span> philosophy. In
        particular, data in different tables is kept consistent through
        the use of <span class="bold"><strong>foreign key
        constraints</strong></span>, which can prevent changes from happening
        or automatically propagate those changes to all related tables.
        Related mechanisms include the <span class="bold"><strong>unique
        constraint</strong></span>, which prevents duplicate values from
        being inserted by mistake, and the <span class="bold"><strong>NOT
        NULL constraint</strong></span>, which prevents blank values from
        being inserted by mistake.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_foreign_key_constraint">FOREIGN KEY constraint</a>, <a class="glossseealso" href="glossary.html#glos_not_null_constraint">NOT NULL constraint</a>, <a class="glossseealso" href="glossary.html#glos_unique_constraint">unique constraint</a>.</p></dd><dt><a name="glos_relational"></a><span class="glossterm">relational</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394879376"></a>
        An important aspect of modern database systems. The database
        server encodes and enforces relationships such as one-to-one,
        one-to-many, many-to-one, and uniqueness. For example, a person
        might have zero, one, or many phone numbers in an address
        database; a single phone number might be associated with several
        family members. In a financial database, a person might be
        required to have exactly one taxpayer ID, and any taxpayer ID
        could only be associated with one person.
      </p><p>
        The database server can use these relationships to prevent bad
        data from being inserted, and to find efficient ways to look up
        information. For example, if a value is declared to be unique,
        the server can stop searching as soon as the first match is
        found, and it can reject attempts to insert a second copy of the
        same value.
      </p><p>
        At the database level, these relationships are expressed through
        SQL features such as <span class="bold"><strong>columns</strong></span>
        within a table, unique and <code class="literal">NOT NULL</code>
        <span class="bold"><strong>constraints</strong></span>,
        <span class="bold"><strong>foreign keys</strong></span>, and different
        kinds of join operations. Complex relationships typically
        involve data split between more than one table. Often, the data
        is <span class="bold"><strong>normalized</strong></span>, so that
        duplicate values in one-to-many relationships are stored only
        once.
      </p><p>
        In a mathematical context, the relations within a database are
        derived from set theory. For example, the <code class="literal">OR</code>
        and <code class="literal">AND</code> operators of a
        <code class="literal">WHERE</code> clause represent the notions of union
        and intersection.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_column">column</a>, <a class="glossseealso" href="glossary.html#glos_constraint">constraint</a>, <a class="glossseealso" href="glossary.html#glos_foreign_key">foreign key</a>, <a class="glossseealso" href="glossary.html#glos_normalized">normalized</a>.</p></dd><dt><a name="glos_relevance"></a><span class="glossterm">relevance</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394866384"></a>
        In the <span class="bold"><strong>full-text search</strong></span>
        feature, a number signifying the similarity between the search
        string and the data in the <span class="bold"><strong>FULLTEXT
        index</strong></span>. For example, when you search for a single
        word, that word is typically more relevant for a row where it
        occurs several times in the text than a row where it appears
        only once.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_full_text_search">full-text search</a>, <a class="glossseealso" href="glossary.html#glos_fulltext_index">FULLTEXT index</a>.</p></dd><dt><a name="glos_repeatable_read"></a><span class="glossterm">REPEATABLE READ</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394861552"></a>
        The default <span class="bold"><strong>isolation level</strong></span> for
        <code class="literal">InnoDB</code>. It prevents any rows that are queried
        from being changed by other
        <span class="bold"><strong>transactions</strong></span>, thus blocking
        <span class="bold"><strong>non-repeatable reads</strong></span> but not
        <span class="bold"><strong>phantom</strong></span> reads. It uses a
        moderately strict <span class="bold"><strong>locking</strong></span>
        strategy so that all queries within a transaction see data from
        the same snapshot, that is, the data as it was at the time the
        transaction started.
      </p><p>
        When a transaction with this isolation level performs
        <code class="literal">UPDATE ... WHERE</code>, <code class="literal">DELETE ...
        WHERE</code>, <code class="literal">SELECT ... FOR UPDATE</code>, and
        <code class="literal">LOCK IN SHARE MODE</code> operations, other
        transactions might have to wait.
      </p><p>
        <code class="literal">SELECT ... FOR SHARE</code> replaces <code class="literal">SELECT
        ... LOCK IN SHARE MODE</code> in MySQL 8.0.1, but
        <code class="literal">LOCK IN SHARE MODE</code> remains available for
        backward compatibility.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_consistent_read">consistent read</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_phantom">phantom</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_repertoire"></a><span class="glossterm">repertoire</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394845904"></a>
        Repertoire is a term applied to character sets. A character set
        repertoire is the collection of characters in the set. See
        <a class="xref" href="charset.html#charset-repertoire" title="10.2.1 Character Set Repertoire">Section 10.2.1, “Character Set Repertoire”</a>.
      </p></dd><dt><a name="glos_replication"></a><span class="glossterm">replication</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394843024"></a>
        The practice of sending changes from a
        <span class="bold"><strong>master database</strong></span>, to one or more
        <span class="bold"><strong>slave databases</strong></span>, so that all
        databases have the same data. This technique has a wide range of
        uses, such as load-balancing for better scalability, disaster
        recovery, and testing software upgrades and configuration
        changes. The changes can be sent between the database by methods
        called <span class="bold"><strong>row-based replication</strong></span>
        and <span class="bold"><strong>statement-based
        replication</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_master_server">master server</a>, <a class="glossseealso" href="glossary.html#glos_row_based_replication">row-based replication</a>, <a class="glossseealso" href="glossary.html#glos_slave_server">slave server</a>, <a class="glossseealso" href="glossary.html#glos_statement_based_replication">statement-based replication</a>.</p></dd><dt><a name="glos_restore"></a><span class="glossterm">restore</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394835536"></a>
        The process of putting a set of backup files from the
        <span class="bold"><strong>MySQL Enterprise Backup</strong></span> product
        in place for use by MySQL. This operation can be performed to
        fix a corrupted database, to return to some earlier point in
        time, or (in a <span class="bold"><strong>replication</strong></span>
        context) to set up a new <span class="bold"><strong>slave
        database</strong></span>. In the <span class="bold"><strong>MySQL
        Enterprise Backup</strong></span> product, this operation is
        performed by the <code class="literal">copy-back</code> option of the
        <code class="literal">mysqlbackup</code> command.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_mysqlbackup_command">mysqlbackup command</a>, <a class="glossseealso" href="glossary.html#glos_prepared_backup">prepared backup</a>, <a class="glossseealso" href="glossary.html#glos_replication">replication</a>, <a class="glossseealso" href="glossary.html#glos_slave_server">slave server</a>.</p></dd><dt><a name="glos_rollback"></a><span class="glossterm">rollback</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394825776"></a>
        A <span class="bold"><strong>SQL</strong></span> statement that ends a
        <span class="bold"><strong>transaction</strong></span>, undoing any
        changes made by the transaction. It is the opposite of
        <span class="bold"><strong>commit</strong></span>, which makes permanent
        any changes made in the transaction.
      </p><p>
        By default, MySQL uses the
        <span class="bold"><strong>autocommit</strong></span> setting, which
        automatically issues a commit following each SQL statement. You
        must change this setting before you can use the rollback
        technique.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_autocommit">autocommit</a>, <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_rollback_segment"></a><span class="glossterm">rollback segment</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394817600"></a>
        The storage area containing the <span class="bold"><strong>undo
        log</strong></span>. Rollback segments have traditionally resided in
        the <span class="bold"><strong>system tablespace</strong></span>. As of
        MySQL 5.6, rollback segments can reside in
        <span class="bold"><strong>undo tablespaces</strong></span>. As of MySQL
        5.7, rollback segments are also allocated to the
        <span class="emphasis"><em>temporary tablespace</em></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_temporary_tablespace">temporary tablespace</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>, <a class="glossseealso" href="glossary.html#glos_undo_tablespace">undo tablespace</a>.</p></dd><dt><a name="glos_row"></a><span class="glossterm">row</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394810704"></a>
        The logical data structure defined by a set of
        <span class="bold"><strong>columns</strong></span>. A set of rows makes up
        a <span class="bold"><strong>table</strong></span>. Within
        <code class="literal">InnoDB</code> <span class="bold"><strong>data
        files</strong></span>, each <span class="bold"><strong>page</strong></span> can
        contain one or more rows.
      </p><p>
        Although <code class="literal">InnoDB</code> uses the term
        <span class="bold"><strong>row format</strong></span> for consistency with
        MySQL syntax, the row format is a property of each table and
        applies to all rows in that table.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_column">column</a>, <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>, <a class="glossseealso" href="glossary.html#glos_row_format">row format</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_row_format"></a><span class="glossterm">row format</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394800544"></a>
        The disk storage format for
        <span class="bold"><strong>rows</strong></span> of an
        <code class="literal">InnoDB</code>
        <span class="bold"><strong>table</strong></span>. As
        <code class="literal">InnoDB</code> gains new capabilities such as
        <span class="bold"><strong>compression</strong></span>, new row formats
        are introduced to support the resulting improvements in storage
        efficiency and performance.
      </p><p>
        The row format of an <code class="literal">InnoDB</code> table is
        specified by the <code class="literal">ROW_FORMAT</code> option or by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_default_row_format"><code class="literal">innodb_default_row_format</code></a>
        configuration option (introduced in MySQL 5.7.9). Row formats
        include <code class="literal">REDUNDANT</code>,
        <code class="literal">COMPACT</code>, <code class="literal">COMPRESSED</code>, and
        <code class="literal">DYNAMIC</code>. To view the row format of an
        <code class="literal">InnoDB</code> table, issue the
        <a class="link" href="sql-syntax.html#show-table-status" title="13.7.6.36 SHOW TABLE STATUS Syntax"><code class="literal">SHOW TABLE STATUS</code></a> statement or
        query <code class="literal">InnoDB</code> table metadata in the
        <a class="link" href="information-schema.html" title="Chapter 24 INFORMATION_SCHEMA Tables"><code class="literal">INFORMATION_SCHEMA</code></a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_compact_row_format">compact row format</a>, <a class="glossseealso" href="glossary.html#glos_compressed_row_format">compressed row format</a>, <a class="glossseealso" href="glossary.html#glos_compression">compression</a>, <a class="glossseealso" href="glossary.html#glos_dynamic_row_format">dynamic row format</a>, <a class="glossseealso" href="glossary.html#glos_redundant_row_format">redundant row format</a>, <a class="glossseealso" href="glossary.html#glos_row">row</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_row_lock"></a><span class="glossterm">row lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394781072"></a>
        A <span class="bold"><strong>lock</strong></span> that prevents a row from
        being accessed in an incompatible way by another
        <span class="bold"><strong>transaction</strong></span>. Other rows in the
        same table can be freely written to by other transactions. This
        is the type of <span class="bold"><strong>locking</strong></span> done by
        <span class="bold"><strong>DML</strong></span> operations on
        <span class="bold"><strong>InnoDB</strong></span> tables.
      </p><p>
        Contrast with <span class="bold"><strong>table locks</strong></span> used
        by <a class="link" href="storage-engines.html#myisam-storage-engine" title="16.2 The MyISAM Storage Engine"><code class="literal">MyISAM</code></a>, or during
        <span class="bold"><strong>DDL</strong></span> operations on
        <code class="literal">InnoDB</code> tables that cannot be done with
        <span class="bold"><strong>online DDL</strong></span>; those locks block
        concurrent access to the table.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_online_ddl">online DDL</a>, <a class="glossseealso" href="glossary.html#glos_table_lock">table lock</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_row_based_replication"></a><span class="glossterm">row-based replication</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394766496"></a>
        A form of <span class="bold"><strong>replication</strong></span> where
        events are propagated from the <span class="bold"><strong>master
        server</strong></span> specifying how to change individual rows on
        the <span class="bold"><strong>slave server</strong></span>. It is safe to
        use for all settings of the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode</code></a>
        option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_auto_increment_locking">auto-increment locking</a>, <a class="glossseealso" href="glossary.html#glos_innodb_autoinc_lock_mode">innodb_autoinc_lock_mode</a>, <a class="glossseealso" href="glossary.html#glos_master_server">master server</a>, <a class="glossseealso" href="glossary.html#glos_replication">replication</a>, <a class="glossseealso" href="glossary.html#glos_slave_server">slave server</a>, <a class="glossseealso" href="glossary.html#glos_statement_based_replication">statement-based replication</a>.</p></dd><dt><a name="glos_row_level_locking"></a><span class="glossterm">row-level locking</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394757744"></a>
        The <span class="bold"><strong>locking</strong></span> mechanism used for
        <span class="bold"><strong>InnoDB</strong></span> tables, relying on
        <span class="bold"><strong>row locks</strong></span> rather than
        <span class="bold"><strong>table locks</strong></span>. Multiple
        <span class="bold"><strong>transactions</strong></span> can modify the
        same table concurrently. Only if two transactions try to modify
        the same row does one of the transactions wait for the other to
        complete (and release its row locks).
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_row_lock">row lock</a>, <a class="glossseealso" href="glossary.html#glos_table_lock">table lock</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_rw_lock"></a><span class="glossterm">rw-lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394749280"></a>
        The low-level object that <code class="literal">InnoDB</code> uses to
        represent and enforce shared-access
        <span class="bold"><strong>locks</strong></span> to internal in-memory
        data structures following certain rules. Contrast with
        <span class="bold"><strong>mutexes</strong></span>, which
        <code class="literal">InnoDB</code> uses to represent and enforce
        exclusive access to internal in-memory data structures. Mutexes
        and rw-locks are known collectively as
        <span class="bold"><strong>latches</strong></span>.
      </p><p>
        <code class="literal">rw-lock</code> types include
        <code class="literal">s-locks</code> (shared locks),
        <code class="literal">x-locks</code> (exclusive locks), and
        <code class="literal">sx-locks</code> (shared-exclusive locks).
</p>
<div class="itemizedlist">
<ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
            An <code class="literal">s-lock</code> provides read access to a
            common resource.
          </p></li><li class="listitem"><p>
            An <code class="literal">x-lock</code> provides write access to a
            common resource while not permitting inconsistent reads by
            other threads.
          </p></li><li class="listitem"><p>
            An <code class="literal">sx-lock</code> provides write access to a
            common resource while permitting inconsistent reads by other
            threads. <code class="literal">sx-locks</code> were introduced in
            MySQL 5.7 to optimize concurrency and improve scalability
            for read-write workloads.
</p></li></ul>
</div>
<p>
        The following matrix summarizes rw-lock type compatibility.
</p>
<div class="informaltable">
<table summary="Compatibility matrix for rw-lock types. Each cell in the matrix is marked as either Compatible or Conflict."><col width="20%"><col width="20%"><col width="20%"><col width="20%"><thead><tr>
            <th scope="col"></th>
            <th scope="col"><em class="replaceable"><code>S</code></em>

            </th>
            <th scope="col"><em class="replaceable"><code>SX</code></em>

            </th>
            <th scope="col"><em class="replaceable"><code>X</code></em>

            </th>
          </tr></thead><tbody><tr>
            <td scope="row"><em class="replaceable"><code>S</code></em>

            </td>
            <td>Compatible</td>
            <td>Compatible</td>
            <td>Conflict</td>
          </tr><tr>
            <td scope="row"><em class="replaceable"><code>SX</code></em>

            </td>
            <td>Compatible</td>
            <td>Conflict</td>
            <td>Conflict</td>
          </tr><tr>
            <td scope="row"><em class="replaceable"><code>X</code></em>

            </td>
            <td>Conflict</td>
            <td>Conflict</td>
            <td>Conflict</td>
</tr></tbody></table>
</div>
<p>See Also <a class="glossseealso" href="glossary.html#glos_latch">latch</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_mutex">mutex</a>, <a class="glossseealso" href="glossary.html#glos_performance_schema">Performance Schema</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">S</h3>
<dl><dt><a name="glos_savepoint"></a><span class="glossterm">savepoint</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394707648"></a>
        Savepoints help to implement nested
        <span class="bold"><strong>transactions</strong></span>. They can be used
        to provide scope to operations on tables that are part of a
        larger transaction. For example, scheduling a trip in a
        reservation system might involve booking several different
        flights; if a desired flight is unavailable, you might
        <span class="bold"><strong>roll back</strong></span> the changes involved
        in booking that one leg, without rolling back the earlier
        flights that were successfully booked.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_scalability"></a><span class="glossterm">scalability</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394702448"></a>
        The ability to add more work and issue more simultaneous
        requests to a system, without a sudden drop in performance due
        to exceeding the limits of system capacity. Software
        architecture, hardware configuration, application coding, and
        type of workload all play a part in scalability. When the system
        reaches its maximum capacity, popular techniques for increasing
        scalability are <span class="bold"><strong>scale up</strong></span>
        (increasing the capacity of existing hardware or software) and
        <span class="bold"><strong>scale out</strong></span> (adding new servers
        and more instances of MySQL). Often paired with
        <span class="bold"><strong>availability</strong></span> as critical
        aspects of a large-scale deployment.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_availability">availability</a>, <a class="glossseealso" href="glossary.html#glos_scale_out">scale out</a>, <a class="glossseealso" href="glossary.html#glos_scale_up">scale up</a>.</p></dd><dt><a name="glos_scale_out"></a><span class="glossterm">scale out</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394695600"></a>
        A technique for increasing
        <span class="bold"><strong>scalability</strong></span> by adding new
        servers and more instances of MySQL. For example, setting up
        replication, NDB Cluster, connection pooling, or other features
        that spread work across a group of servers. Contrast with
        <span class="bold"><strong>scale up</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_scalability">scalability</a>, <a class="glossseealso" href="glossary.html#glos_scale_up">scale up</a>.</p></dd><dt><a name="glos_scale_up"></a><span class="glossterm">scale up</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394690816"></a>
        A technique for increasing
        <span class="bold"><strong>scalability</strong></span> by increasing the
        capacity of existing hardware or software. For example,
        increasing the memory on a server and adjusting memory-related
        parameters such as
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_buffer_pool_size"><code class="literal">innodb_buffer_pool_size</code></a> and
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_buffer_pool_instances"><code class="literal">innodb_buffer_pool_instances</code></a>.
        Contrast with <span class="bold"><strong>scale out</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_scalability">scalability</a>, <a class="glossseealso" href="glossary.html#glos_scale_out">scale out</a>.</p></dd><dt><a name="glos_schema"></a><span class="glossterm">schema</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394683504"></a>
        Conceptually, a schema is a set of interrelated database
        objects, such as tables, table columns, data types of the
        columns, indexes, foreign keys, and so on. These objects are
        connected through SQL syntax, because the columns make up the
        tables, the foreign keys refer to tables and columns, and so on.
        Ideally, they are also connected logically, working together as
        part of a unified application or flexible framework. For
        example, the <span class="bold"><strong>INFORMATION_SCHEMA</strong></span>
        and <span class="bold"><strong>performance_schema</strong></span>
        databases use <span class="quote">“<span class="quote">schema</span>”</span> in their names to emphasize
        the close relationships between the tables and columns they
        contain.
      </p><p>
        In MySQL, physically, a <span class="bold"><strong>schema</strong></span>
        is synonymous with a <span class="bold"><strong>database</strong></span>.
        You can substitute the keyword <code class="literal">SCHEMA</code> instead
        of <code class="literal">DATABASE</code> in MySQL SQL syntax, for example
        using <code class="literal">CREATE SCHEMA</code> instead of
        <code class="literal">CREATE DATABASE</code>.
      </p><p>
        Some other database products draw a distinction. For example, in
        the Oracle Database product, a
        <span class="bold"><strong>schema</strong></span> represents only a part
        of a database: the tables and other objects owned by a single
        user.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_database">database</a>, <a class="glossseealso" href="glossary.html#glos_information_schema">INFORMATION_SCHEMA</a>, <a class="glossseealso" href="glossary.html#glos_performance_schema">Performance Schema</a>.</p></dd><dt><a name="glos_sdi"></a><span class="glossterm">SDI</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394671248"></a>
        Acronym for <span class="quote">“<span class="quote">serialized dictionary information</span>”</span>.
      </p><a class="indexterm" name="idm139899394669872"></a><a class="indexterm" name="idm139899394668832"></a><p>See Also <a class="glossseealso" href="glossary.html#glos_serialized_dictionary_information">Serialized Dictionary Information (SDI)</a>.</p></dd><dt><a name="glos_search_index"></a><span class="glossterm">search index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394665664"></a>
        In MySQL, <span class="bold"><strong>full-text search</strong></span>
        queries use a special kind of index, the
        <span class="bold"><strong>FULLTEXT index</strong></span>. In MySQL 5.6.4
        and up, <code class="literal">InnoDB</code> and <code class="literal">MyISAM</code>
        tables both support <code class="literal">FULLTEXT</code> indexes;
        formerly, these indexes were only available for
        <code class="literal">MyISAM</code> tables.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_full_text_search">full-text search</a>, <a class="glossseealso" href="glossary.html#glos_fulltext_index">FULLTEXT index</a>.</p></dd><dt><a name="glos_secondary_index"></a><span class="glossterm">secondary index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394658144"></a>
        A type of <code class="literal">InnoDB</code>
        <span class="bold"><strong>index</strong></span> that represents a subset
        of table columns. An <code class="literal">InnoDB</code> table can have
        zero, one, or many secondary indexes. (Contrast with the
        <span class="bold"><strong>clustered index</strong></span>, which is
        required for each <code class="literal">InnoDB</code> table, and stores
        the data for all the table columns.)
      </p><p>
        A secondary index can be used to satisfy queries that only
        require values from the indexed columns. For more complex
        queries, it can be used to identify the relevant rows in the
        table, which are then retrieved through lookups using the
        clustered index.
      </p><p>
        Creating and dropping secondary indexes has traditionally
        involved significant overhead from copying all the data in the
        <code class="literal">InnoDB</code> table. The <span class="bold"><strong>fast
        index creation</strong></span> feature makes both <code class="literal">CREATE
        INDEX</code> and <code class="literal">DROP INDEX</code> statements
        much faster for <code class="literal">InnoDB</code> secondary indexes.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_clustered_index">clustered index</a>, <a class="glossseealso" href="glossary.html#glos_fast_index_creation">Fast Index Creation</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>.</p></dd><dt><a name="glos_segment"></a><span class="glossterm">segment</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394645920"></a>
        A division within an <code class="literal">InnoDB</code>
        <span class="bold"><strong>tablespace</strong></span>. If a tablespace is
        analogous to a directory, the segments are analogous to files
        within that directory. A segment can grow. New segments can be
        created.
      </p><p>
        For example, within a
        <span class="bold"><strong>file-per-table</strong></span> tablespace,
        table data is in one segment and each associated index is in its
        own segment. The <span class="bold"><strong>system
        tablespace</strong></span> contains many different segments, because
        it can hold many tables and their associated indexes. Prior to
        MySQL 8.0, the system tablespace also includes one or more
        <span class="bold"><strong>rollback segments</strong></span> used for
        <span class="bold"><strong>undo logs</strong></span>.
      </p><p>
        Segments grow and shrink as data is inserted and deleted. When a
        segment needs more room, it is extended by one
        <span class="bold"><strong>extent</strong></span> (1 megabyte) at a time.
        Similarly, a segment releases one extent's worth of space when
        all the data in that extent is no longer needed.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_extent">extent</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_rollback_segment">rollback segment</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>.</p></dd><dt><a name="glos_selectivity"></a><span class="glossterm">selectivity</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394634160"></a>
        A property of data distribution, the number of distinct values
        in a column (its <span class="bold"><strong>cardinality</strong></span>)
        divided by the number of records in the table. High selectivity
        means that the column values are relatively unique, and can
        retrieved efficiently through an index. If you (or the query
        optimizer) can predict that a test in a <code class="literal">WHERE</code>
        clause only matches a small number (or proportion) of rows in a
        table, the overall <span class="bold"><strong>query</strong></span> tends
        to be efficient if it evaluates that test first, using an index.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_cardinality">cardinality</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>.</p></dd><dt><a name="glos_semi_consistent_read"></a><span class="glossterm">semi-consistent read</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394628304"></a>
        A type of read operation used for <code class="literal">UPDATE</code>
        statements, that is a combination of <span class="bold"><strong>READ
        COMMITTED</strong></span> and <span class="bold"><strong>consistent
        read</strong></span>. When an <code class="literal">UPDATE</code> statement
        examines a row that is already locked, <code class="literal">InnoDB</code>
        returns the latest committed version to MySQL so that MySQL can
        determine whether the row matches the <code class="literal">WHERE</code>
        condition of the <code class="literal">UPDATE</code>. If the row matches
        (must be updated), MySQL reads the row again, and this time
        <code class="literal">InnoDB</code> either locks it or waits for a lock on
        it. This type of read operation can only happen when the
        transaction has the READ COMMITTED
        <span class="bold"><strong>isolation level</strong></span>, or when the
        <a class="ulink" href="http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_locks_unsafe_for_binlog" target="_top"><code class="literal">innodb_locks_unsafe_for_binlog</code></a>
        option is enabled.
        <a class="ulink" href="http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_locks_unsafe_for_binlog" target="_top"><code class="literal">innodb_locks_unsafe_for_binlog</code></a>
        was removed in MySQL 8.0.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_consistent_read">consistent read</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_read_committed">READ COMMITTED</a>.</p></dd><dt><a name="glos_serializable"></a><span class="glossterm">SERIALIZABLE</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394615328"></a>
        The <span class="bold"><strong>isolation level</strong></span> that uses
        the most conservative locking strategy, to prevent any other
        <span class="bold"><strong>transactions</strong></span> from inserting or
        changing data that was read by this transaction, until it is
        finished. This way, the same query can be run over and over
        within a transaction, and be certain to retrieve the same set of
        results each time. Any attempt to change data that was committed
        by another transaction since the start of the current
        transaction, cause the current transaction to wait.
      </p><p>
        This is the default isolation level specified by the SQL
        standard. In practice, this degree of strictness is rarely
        needed, so the default isolation level for
        <code class="literal">InnoDB</code> is the next most strict,
        <span class="bold"><strong>REPEATABLE READ</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_consistent_read">consistent read</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_repeatable_read">REPEATABLE READ</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_serialized_dictionary_information"></a><span class="glossterm">Serialized Dictionary Information (SDI)</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394606176"></a>
        Dictionary object metadata in serialized form. SDI is stored in
        <code class="literal">JSON</code> format.
      </p><p>
        As of MySQL 8.0.3, SDI is present in all
        <code class="literal">InnoDB</code> tablespace files except for temporary
        tablespace and undo tablespace files. The presence of SDI in
        tablespace files provides metadata redundancy. For example,
        dictionary object metadata can be extracted from tablespace
        files using the <a class="link" href="programs.html#ibd2sdi" title="4.6.1 ibd2sdi — InnoDB Tablespace SDI Extraction Utility"><span class="command"><strong>ibd2sdi</strong></span></a> utility if the data
        dictionary becomes unavailable.
      </p><p>
        For a <code class="literal">MyISAM</code> table, SDI is stored in a
        <code class="filename">.sdi</code> metadata file in the schema directory.
        An SDI metadata file is required to perform an
        <a class="link" href="sql-syntax.html#import-table" title="13.2.5 IMPORT TABLE Syntax"><code class="literal">IMPORT TABLE</code></a> operation.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_general_tablespace">general tablespace</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>.</p></dd><dt><a name="glos_server"></a><span class="glossterm">server</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394595440"></a>
        A type of program that runs continuously, waiting to receive and
        act upon requests from another program (the
        <span class="bold"><strong>client</strong></span>). Because often an
        entire computer is dedicated to running one or more server
        programs (such as a database server, a web server, an
        application server, or some combination of these), the term
        <span class="bold"><strong>server</strong></span> can also refer to the
        computer that runs the server software.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_client">client</a>, <a class="glossseealso" href="glossary.html#glos_mysqld">mysqld</a>.</p></dd><dt><a name="glos_shared_lock"></a><span class="glossterm">shared lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394590448"></a>
        A kind of <span class="bold"><strong>lock</strong></span> that allows
        other <span class="bold"><strong>transactions</strong></span> to read the
        locked object, and to also acquire other shared locks on it, but
        not to write to it. The opposite of
        <span class="bold"><strong>exclusive lock</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_exclusive_lock">exclusive lock</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_shared_tablespace"></a><span class="glossterm">shared tablespace</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394584480"></a>
        Another way of referring to the <span class="bold"><strong>system
        tablespace</strong></span> or to a <span class="bold"><strong>general
        tablespace</strong></span>. General tablespaces were introduced in
        MySQL 5.7
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_general_tablespace">general tablespace</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>.</p></dd><dt><a name="glos_sharp_checkpoint"></a><span class="glossterm">sharp checkpoint</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394579824"></a>
        The process of <span class="bold"><strong>flushing</strong></span> to disk
        all <span class="bold"><strong>dirty</strong></span> buffer pool pages
        whose redo entries are contained in certain portion of the
        <span class="bold"><strong>redo log</strong></span>. Occurs before
        <code class="literal">InnoDB</code> reuses a portion of a log file; the
        log files are used in a circular fashion. Typically occurs with
        write-intensive <span class="bold"><strong>workloads</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_dirty_page">dirty page</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_redo_log">redo log</a>, <a class="glossseealso" href="glossary.html#glos_workload">workload</a>.</p></dd><dt><a name="glos_shutdown"></a><span class="glossterm">shutdown</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394571936"></a>
        The process of stopping the MySQL server. By default, this
        process cleans up operations for
        <span class="bold"><strong>InnoDB</strong></span> tables, so
        <code class="literal">InnoDB</code> can be
        <span class="bold"><strong>slow</strong></span> to shut down, but fast to
        start up later. If you skip the cleanup operations, it is
        <span class="bold"><strong>fast</strong></span> to shut down but the
        cleanup must be performed during the next restart.
      </p><p>
        The shutdown mode for <code class="literal">InnoDB</code> is controlled by
        the <a class="link" href="innodb-storage-engine.html#sysvar_innodb_fast_shutdown"><code class="literal">innodb_fast_shutdown</code></a>
        option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_fast_shutdown">fast shutdown</a>, <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_slow_shutdown">slow shutdown</a>, <a class="glossseealso" href="glossary.html#glos_startup">startup</a>.</p></dd><dt><a name="glos_slave_server"></a><span class="glossterm">slave server</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394562256"></a>
        Frequently shortened to <span class="quote">“<span class="quote">slave</span>”</span>. A database
        <span class="bold"><strong>server</strong></span> machine in a
        <span class="bold"><strong>replication</strong></span> scenario that
        receives changes from another server (the
        <span class="bold"><strong>master</strong></span>) and applies those same
        changes. Thus it maintains the same contents as the master,
        although it might lag somewhat behind.
      </p><p>
        In MySQL, slave servers are commonly used in disaster recovery,
        to take the place of a master servers that fails. They are also
        commonly used for testing software upgrades and new settings, to
        ensure that database configuration changes do not cause problems
        with performance or reliability.
      </p><p>
        Slave servers typically have high workloads, because they
        process all the <span class="bold"><strong>DML</strong></span> (write)
        operations relayed from the master, as well as user queries. To
        ensure that slave servers can apply changes from the master fast
        enough, they frequently have fast I/O devices and sufficient CPU
        and memory to run multiple database instances on the same slave
        server. For example, the master server might use hard drive
        storage while the slave servers use
        <span class="bold"><strong>SSD</strong></span>s.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_master_server">master server</a>, <a class="glossseealso" href="glossary.html#glos_replication">replication</a>, <a class="glossseealso" href="glossary.html#glos_server">server</a>, <a class="glossseealso" href="glossary.html#glos_ssd">SSD</a>.</p></dd><dt><a name="glos_slow_query_log"></a><span class="glossterm">slow query log</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394551792"></a>
        A type of <span class="bold"><strong>log</strong></span> used for
        performance tuning of SQL statements processed by the MySQL
        server. The log information is stored in a file. You must enable
        this feature to use it. You control which categories of
        <span class="quote">“<span class="quote">slow</span>”</span> SQL statements are logged. For more
        information, see <a class="xref" href="server-administration.html#slow-query-log" title="5.4.5 The Slow Query Log">Section 5.4.5, “The Slow Query Log”</a>.

      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_general_query_log">general query log</a>, <a class="glossseealso" href="glossary.html#glos_log">log</a>.</p></dd><dt><a name="glos_slow_shutdown"></a><span class="glossterm">slow shutdown</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394546624"></a>
        A type of <span class="bold"><strong>shutdown</strong></span> that does
        additional <code class="literal">InnoDB</code> flushing operations before
        completing. Also known as a <span class="bold"><strong>clean
        shutdown</strong></span>. Specified by the configuration parameter
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_fast_shutdown"><code class="literal">innodb_fast_shutdown=0</code></a> or the
        command <code class="literal">SET GLOBAL innodb_fast_shutdown=0;</code>.
        Although the shutdown itself can take longer, that time will be
        saved on the subsequent startup.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_clean_shutdown">clean shutdown</a>, <a class="glossseealso" href="glossary.html#glos_fast_shutdown">fast shutdown</a>, <a class="glossseealso" href="glossary.html#glos_shutdown">shutdown</a>.</p></dd><dt><a name="glos_snapshot"></a><span class="glossterm">snapshot</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394538624"></a>
        A representation of data at a particular time, which remains the
        same even as changes are
        <span class="bold"><strong>committed</strong></span> by other
        <span class="bold"><strong>transactions</strong></span>. Used by certain
        <span class="bold"><strong>isolation levels</strong></span> to allow
        <span class="bold"><strong>consistent reads</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_consistent_read">consistent read</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_sort_buffer"></a><span class="glossterm">sort buffer</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394531504"></a>
        The buffer used for sorting data during creation of an
        <code class="literal">InnoDB</code> index. Sort buffer size is configured
        using the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_sort_buffer_size"><code class="literal">innodb_sort_buffer_size</code></a>
        configuration option.
      </p></dd><dt><a name="glos_space_id"></a><span class="glossterm">space ID</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394527312"></a>
        An identifier used to uniquely identify an
        <code class="literal">InnoDB</code>
        <span class="bold"><strong>tablespace</strong></span> within a MySQL
        instance. The space ID for the <span class="bold"><strong>system
        tablespace</strong></span> is always zero; this same ID applies to
        all tables within the system tablespace or within a general
        tablespace. Each <span class="bold"><strong>file-per-table</strong></span>
        tablespace and <span class="bold"><strong>general
        tablespace</strong></span> has its own space ID.
      </p><p>
        Prior to MySQL 5.6, this hardcoded value presented difficulties
        in moving <code class="literal">InnoDB</code> tablespace files between
        MySQL instances. Starting in MySQL 5.6, you can copy tablespace
        files between instances by using the
        <span class="bold"><strong>transportable tablespace</strong></span>
        feature involving the statements <code class="literal">FLUSH TABLES ... FOR
        EXPORT</code>, <code class="literal">ALTER TABLE ... DISCARD
        TABLESPACE</code>, and <code class="literal">ALTER TABLE ... IMPORT
        TABLESPACE</code>. The information needed to adjust the space
        ID is conveyed in the <span class="bold"><strong>.cfg file</strong></span>
        which you copy along with the tablespace. See
        <a class="xref" href="innodb-storage-engine.html#tablespace-copying" title="15.7.6 Copying File-Per-Table Tablespaces to Another Instance">Section 15.7.6, “Copying File-Per-Table Tablespaces to Another Instance”</a> for details.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_cfg_file">.cfg file</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_general_tablespace">general tablespace</a>, <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>, <a class="glossseealso" href="glossary.html#glos_transportable_tablespace">transportable tablespace</a>.</p></dd><dt><a name="glos_sparse_file"></a><span class="glossterm">sparse file</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394511920"></a>
        A type of file that uses file system space more efficiently by
        writing metadata representing empty blocks to disk instead of
        writing the actual empty space. The <code class="literal">InnoDB</code>
        <span class="bold"><strong>transparent page compression</strong></span>
        feature relies on sparse file support. For more information, see
        <a class="xref" href="innodb-storage-engine.html#innodb-page-compression" title="15.9.2 InnoDB Page Compression">Section 15.9.2, “InnoDB Page Compression”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_hole_punching">hole punching</a>, <a class="glossseealso" href="glossary.html#glos_transparent_page_compression">transparent page compression</a>.</p></dd><dt><a name="glos_spin"></a><span class="glossterm">spin</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394506448"></a>
        A type of <span class="bold"><strong>wait</strong></span> operation that
        continuously tests whether a resource becomes available. This
        technique is used for resources that are typically held only for
        brief periods, where it is more efficient to wait in a
        <span class="quote">“<span class="quote">busy loop</span>”</span> than to put the thread to sleep and
        perform a context switch. If the resource does not become
        available within a short time, the spin loop ceases and another
        wait technique is used.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_latch">latch</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_mutex">mutex</a>, <a class="glossseealso" href="glossary.html#glos_wait">wait</a>.</p></dd><dt><a name="glos_sql"></a><span class="glossterm">SQL</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394500800"></a>
        The Structured Query Language that is standard for performing
        database operations. Often divided into the categories
        <span class="bold"><strong>DDL</strong></span>,
        <span class="bold"><strong>DML</strong></span>, and
        <span class="bold"><strong>queries</strong></span>. MySQL includes some
        additional statement categories such as
        <span class="bold"><strong>replication</strong></span>. See
        <a class="xref" href="language-structure.html" title="Chapter 9 Language Structure">Chapter 9, <i>Language Structure</i></a> for the building blocks of
        SQL syntax, <a class="xref" href="data-types.html" title="Chapter 11 Data Types">Chapter 11, <i>Data Types</i></a> for the data types to
        use for MySQL table columns, <a class="xref" href="sql-syntax.html" title="Chapter 13 SQL Statement Syntax">Chapter 13, <i>SQL Statement Syntax</i></a> for
        details about SQL statements and their associated categories,
        and <a class="xref" href="functions.html" title="Chapter 12 Functions and Operators">Chapter 12, <i>Functions and Operators</i></a> for standard and MySQL-specific
        functions to use in queries.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>, <a class="glossseealso" href="glossary.html#glos_replication">replication</a>.</p></dd><dt><a name="glos_ssd"></a><span class="glossterm">SSD</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394490832"></a>
        Acronym for <span class="quote">“<span class="quote">solid-state drive</span>”</span>. A type of storage
        device with different performance characteristics than a
        traditional hard disk drive
        (<span class="bold"><strong>HDD</strong></span>): smaller storage
        capacity, faster for random reads, no moving parts, and with a
        number of considerations affecting write performance. Its
        performance characteristics can influence the throughput of a
        <span class="bold"><strong>disk-bound</strong></span> workload.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_disk_bound">disk-bound</a>, <a class="glossseealso" href="glossary.html#glos_hdd">HDD</a>.</p></dd><dt><a name="glos_startup"></a><span class="glossterm">startup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394485664"></a>
        The process of starting the MySQL server. Typically done by one
        of the programs listed in <a class="xref" href="programs.html#programs-server" title="4.3 MySQL Server and Server-Startup Programs">Section 4.3, “MySQL Server and Server-Startup Programs”</a>. The
        opposite of <span class="bold"><strong>shutdown</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_shutdown">shutdown</a>.</p></dd><dt><a name="glos_statement_based_replication"></a><span class="glossterm">statement-based replication</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394481552"></a>
        A form of <span class="bold"><strong>replication</strong></span> where SQL
        statements are sent from the <span class="bold"><strong>master
        server</strong></span> and replayed on the
        <span class="bold"><strong>slave server</strong></span>. It requires some
        care with the setting for the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_autoinc_lock_mode"><code class="literal">innodb_autoinc_lock_mode</code></a>
        option, to avoid potential timing problems with
        <span class="bold"><strong>auto-increment locking</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_auto_increment_locking">auto-increment locking</a>, <a class="glossseealso" href="glossary.html#glos_innodb_autoinc_lock_mode">innodb_autoinc_lock_mode</a>, <a class="glossseealso" href="glossary.html#glos_master_server">master server</a>, <a class="glossseealso" href="glossary.html#glos_replication">replication</a>, <a class="glossseealso" href="glossary.html#glos_row_based_replication">row-based replication</a>, <a class="glossseealso" href="glossary.html#glos_slave_server">slave server</a>.</p></dd><dt><a name="glos_statistics"></a><span class="glossterm">statistics</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394472080"></a>
        Estimated values relating to each <code class="literal">InnoDB</code>
        <span class="bold"><strong>table</strong></span> and
        <span class="bold"><strong>index</strong></span>, used to construct an
        efficient <span class="bold"><strong>query execution plan</strong></span>.
        The main values are the
        <span class="bold"><strong>cardinality</strong></span> (number of distinct
        values) and the total number of table rows or index entries. The
        statistics for the table represent the data in its
        <span class="bold"><strong>primary key</strong></span> index. The
        statistics for a <span class="bold"><strong>secondary
        index</strong></span> represent the rows covered by that index.
      </p><p>
        The values are estimated rather than counted precisely because
        at any moment, different
        <span class="bold"><strong>transactions</strong></span> can be inserting
        and deleting rows from the same table. To keep the values from
        being recalculated frequently, you can enable
        <span class="bold"><strong>persistent statistics</strong></span>, where
        the values are stored in <code class="literal">InnoDB</code> system
        tables, and refreshed only when you issue an
        <a class="link" href="sql-syntax.html#analyze-table" title="13.7.3.1 ANALYZE TABLE Syntax"><code class="literal">ANALYZE TABLE</code></a> statement.
      </p><p>
        You can control how <span class="bold"><strong>NULL</strong></span> values
        are treated when calculating statistics through the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_stats_method"><code class="literal">innodb_stats_method</code></a>
        configuration option.
      </p><p>
        Other types of statistics are available for database objects and
        database activity through the
        <span class="bold"><strong>INFORMATION_SCHEMA</strong></span> and
        <span class="bold"><strong>PERFORMANCE_SCHEMA</strong></span> tables.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_cardinality">cardinality</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_information_schema">INFORMATION_SCHEMA</a>, <a class="glossseealso" href="glossary.html#glos_null">NULL</a>, <a class="glossseealso" href="glossary.html#glos_performance_schema">Performance Schema</a>, <a class="glossseealso" href="glossary.html#glos_persistent_statistics">persistent statistics</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>, <a class="glossseealso" href="glossary.html#glos_query_execution_plan">query execution plan</a>, <a class="glossseealso" href="glossary.html#glos_secondary_index">secondary index</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_stemming"></a><span class="glossterm">stemming</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394450384"></a>
        The ability to search for different variations of a word based
        on a common root word, such as singular and plural, or past,
        present, and future verb tense. This feature is currently
        supported in <code class="literal">MyISAM</code>
        <span class="bold"><strong>full-text search</strong></span> feature but
        not in <span class="bold"><strong>FULLTEXT indexes</strong></span> for
        <code class="literal">InnoDB</code> tables.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_full_text_search">full-text search</a>, <a class="glossseealso" href="glossary.html#glos_fulltext_index">FULLTEXT index</a>.</p></dd><dt><a name="glos_stopword"></a><span class="glossterm">stopword</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394444208"></a>
        In a <span class="bold"><strong>FULLTEXT index</strong></span>, a word
        that is considered common or trivial enough that it is omitted
        from the <span class="bold"><strong>search index</strong></span> and
        ignored in search queries. Different configuration settings
        control stopword processing for <code class="literal">InnoDB</code> and
        <code class="literal">MyISAM</code> tables. See
        <a class="xref" href="functions.html#fulltext-stopwords" title="12.9.4 Full-Text Stopwords">Section 12.9.4, “Full-Text Stopwords”</a> for details.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_fulltext_index">FULLTEXT index</a>, <a class="glossseealso" href="glossary.html#glos_search_index">search index</a>.</p></dd><dt><a name="glos_storage_engine"></a><span class="glossterm">storage engine</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394437440"></a>
        A component of the MySQL database that performs the low-level
        work of storing, updating, and querying data. In MySQL 5.5 and
        higher, <span class="bold"><strong>InnoDB</strong></span> is the default
        storage engine for new tables, superceding
        <code class="literal">MyISAM</code>. Different storage engines are
        designed with different tradeoffs between factors such as memory
        usage versus disk usage, read speed versus write speed, and
        speed versus robustness. Each storage engine manages specific
        tables, so we refer to <a class="link" href="innodb-storage-engine.html" title="Chapter 15 The InnoDB Storage Engine"><code class="literal">InnoDB</code></a>
        tables, <a class="link" href="storage-engines.html#myisam-storage-engine" title="16.2 The MyISAM Storage Engine"><code class="literal">MyISAM</code></a> tables, and so on.
      </p><p>
        The <span class="bold"><strong>MySQL Enterprise Backup</strong></span>
        product is optimized for backing up <code class="literal">InnoDB</code>
        tables. It can also back up tables handled by
        <code class="literal">MyISAM</code> and other storage engines.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_table_type">table type</a>.</p></dd><dt><a name="glos_stored_generated_column"></a><span class="glossterm">stored generated column</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394426608"></a>
        A column whose values are computed from an expression included
        in the column definition. Column values are evaluated and stored
        when rows are inserted or updated. A stored generated column
        requires storage space and can be indexed.
      </p><p>
        Contrast with <span class="bold"><strong>virtual generated
        column</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_base_column">base column</a>, <a class="glossseealso" href="glossary.html#glos_generated_column">generated column</a>, <a class="glossseealso" href="glossary.html#glos_virtual_generated_column">virtual generated column</a>.</p></dd><dt><a name="glos_strict_mode"></a><span class="glossterm">strict mode</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394421616"></a>
        The general name for the setting controlled by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_strict_mode"><code class="literal">innodb_strict_mode</code></a> option.
        Turning on this setting causes certain conditions that are
        normally treated as warnings, to be considered errors. For
        example, certain invalid combinations of options related to
        <span class="bold"><strong>file format</strong></span> and
        <span class="bold"><strong>row format</strong></span>, that normally
        produce a warning and continue with default values, now cause
        the <code class="literal">CREATE TABLE</code> operation to fail.
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_strict_mode"><code class="literal">innodb_strict_mode</code></a> is enabled
        by default in MySQL 5.7.
      </p><p>
        MySQL also has something called strict mode. See
        <a class="xref" href="server-administration.html#sql-mode" title="5.1.8 Server SQL Modes">Section 5.1.8, “Server SQL Modes”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_file_format">file format</a>, <a class="glossseealso" href="glossary.html#glos_innodb_strict_mode">innodb_strict_mode</a>, <a class="glossseealso" href="glossary.html#glos_row_format">row format</a>.</p></dd><dt><a name="glos_sublist"></a><span class="glossterm">sublist</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394411840"></a>
        Within the list structure that represents the
        <span class="bold"><strong>buffer pool</strong></span>, pages that are
        relatively old and relatively new are represented by different
        portions of the <span class="bold"><strong>list</strong></span>. A set of
        parameters control the size of these portions and the dividing
        point between the new and old pages.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_eviction">eviction</a>, <a class="glossseealso" href="glossary.html#glos_list">list</a>, <a class="glossseealso" href="glossary.html#glos_lru">LRU</a>.</p></dd><dt><a name="glos_supremum_record"></a><span class="glossterm">supremum record</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394406016"></a>
        A <span class="bold"><strong>pseudo-record</strong></span> in an index,
        representing the <span class="bold"><strong>gap</strong></span> above the
        largest value in that index. If a transaction has a statement
        such as <code class="literal">SELECT ... FROM ... WHERE col &gt; 10 FOR
        UPDATE;</code>, and the largest value in the column is 20, it
        is a lock on the supremum record that prevents other
        transactions from inserting even larger values such as 50, 100,
        and so on.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_gap">gap</a>, <a class="glossseealso" href="glossary.html#glos_infimum_record">infimum record</a>, <a class="glossseealso" href="glossary.html#glos_pseudo_record">pseudo-record</a>.</p></dd><dt><a name="glos_surrogate_key"></a><span class="glossterm">surrogate key</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394399936"></a>
        Synonym name for <span class="bold"><strong>synthetic key</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_synthetic_key">synthetic key</a>.</p></dd><dt><a name="glos_synthetic_key"></a><span class="glossterm">synthetic key</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394396672"></a>
        An indexed column, typically a <span class="bold"><strong>primary
        key</strong></span>, where the values are assigned arbitrarily. Often
        done using an <span class="bold"><strong>auto-increment</strong></span>
        column. By treating the value as completely arbitrary, you can
        avoid overly restrictive rules and faulty application
        assumptions. For example, a numeric sequence representing
        employee numbers might have a gap if an employee was approved
        for hiring but never actually joined. Or employee number 100
        might have a later hiring date than employee number 500, if they
        left the company and later rejoined. Numeric values also produce
        shorter values of predictable length. For example, storing
        numeric codes meaning <span class="quote">“<span class="quote">Road</span>”</span>,
        <span class="quote">“<span class="quote">Boulevard</span>”</span>, <span class="quote">“<span class="quote">Expressway</span>”</span>, and so on
        is more space-efficient than repeating those strings over and
        over.
      </p><p>
        Also known as a <span class="bold"><strong>surrogate key</strong></span>.
        Contrast with <span class="bold"><strong>natural key</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_auto_increment">auto-increment</a>, <a class="glossseealso" href="glossary.html#glos_natural_key">natural key</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>, <a class="glossseealso" href="glossary.html#glos_surrogate_key">surrogate key</a>.</p></dd><dt><a name="glos_system_tablespace"></a><span class="glossterm">system tablespace</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394387040"></a>
        One or more data files (<span class="bold"><strong>ibdata
        files</strong></span>) containing the metadata for
        <code class="literal">InnoDB</code>-related objects, and the storage areas
        for the <span class="bold"><strong>change buffer</strong></span>, and the
        <span class="bold"><strong>doublewrite buffer</strong></span>. It may also
        contain table and index data for <code class="literal">InnoDB</code>
        tables if tables were created in the system tablespace instead
        of <span class="bold"><strong>file-per-table</strong></span> or
        <span class="bold"><strong>general tablespaces</strong></span>. The data
        and metadata in the system tablespace apply to all
        <span class="bold"><strong>databases</strong></span> in a MySQL
        <span class="bold"><strong>instance</strong></span>.
      </p><p>
        Prior to MySQL 5.6.7, the default was to keep all
        <code class="literal">InnoDB</code> tables and indexes inside the system
        tablespace, often causing this file to become very large.
        Because the system tablespace never shrinks, storage problems
        could arise if large amounts of temporary data were loaded and
        then deleted. In MySQL 8.0, the default is
        <span class="bold"><strong>file-per-table</strong></span> mode, where each
        table and its associated indexes are stored in a separate
        <span class="bold"><strong>.ibd file</strong></span>. This default makes
        it easier to use <code class="literal">InnoDB</code> features that rely on
        <code class="literal">DYNAMIC</code> and <code class="literal">COMPRESSED</code> row
        formats, such as table
        <span class="bold"><strong>compression</strong></span>, efficient storage
        of <span class="bold"><strong>off-page columns</strong></span>, and large
        index key prefixes.
      </p><p>
        Keeping all table data in the system tablespace or in separate
        <code class="filename">.ibd</code> files has implications for storage
        management in general. The <span class="bold"><strong>MySQL
        Enterprise Backup</strong></span> product might back up a small set
        of large files, or many smaller files. On systems with thousands
        of tables, the file system operations to process thousands of
        <code class="filename">.ibd</code> files can cause bottlenecks.
      </p><p>
        <code class="literal">InnoDB</code> introduced general tablespaces in
        MySQL 5.7.6, which are also represented by
        <code class="filename">.ibd</code> files. General tablespaces are shared
        tablespaces created using <a class="link" href="sql-syntax.html#create-tablespace" title="13.1.19 CREATE TABLESPACE Syntax"><code class="literal">CREATE
        TABLESPACE</code></a> syntax. They can be created outside of the
        MySQL data directory, are capable of holding multiple tables,
        and support tables of all row formats.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_change_buffer">change buffer</a>, <a class="glossseealso" href="glossary.html#glos_compression">compression</a>, <a class="glossseealso" href="glossary.html#glos_data_dictionary">data dictionary</a>, <a class="glossseealso" href="glossary.html#glos_database">database</a>, <a class="glossseealso" href="glossary.html#glos_doublewrite_buffer">doublewrite buffer</a>, <a class="glossseealso" href="glossary.html#glos_dynamic_row_format">dynamic row format</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_general_tablespace">general tablespace</a>, <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_ibdata_file">ibdata file</a>, <a class="glossseealso" href="glossary.html#glos_innodb_file_per_table">innodb_file_per_table</a>, <a class="glossseealso" href="glossary.html#glos_instance">instance</a>, <a class="glossseealso" href="glossary.html#glos_mysql_enterprise_backup">MySQL Enterprise Backup</a>, <a class="glossseealso" href="glossary.html#glos_off_page_column">off-page column</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">T</h3>
<dl><dt><a name="glos_table"></a><span class="glossterm">table</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394356560"></a>
        Each MySQL table is associated with a particular
        <span class="bold"><strong>storage engine</strong></span>.
        <span class="bold"><strong>InnoDB</strong></span> tables have particular
        <span class="bold"><strong>physical</strong></span> and
        <span class="bold"><strong>logical</strong></span> characteristics that
        affect performance,
        <span class="bold"><strong>scalability</strong></span>,
        <span class="bold"><strong>backup</strong></span>, administration, and
        application development.
      </p><p>
        In terms of file storage, an <code class="literal">InnoDB</code> table
        belongs to one of the following tablespace types:
</p>
<div class="itemizedlist">
<ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
            The shared <code class="literal">InnoDB</code>
            <span class="bold"><strong>system tablespace</strong></span>, which is
            comprised of one or more <span class="bold"><strong>ibdata
            files</strong></span>.
          </p></li><li class="listitem"><p>
            A <span class="bold"><strong>file-per-table</strong></span>
            tablespace, comprised of an individual
            <span class="bold"><strong>.ibd file</strong></span>.
          </p></li><li class="listitem"><p>
            A shared <span class="bold"><strong>general
            tablespace</strong></span>, comprised of an individual
            <code class="filename">.ibd</code> file. General tablespaces were
            introduced in MySQL 5.7.6.
</p></li></ul>
</div>
<p>
        <span class="bold"><strong><code class="literal">.ibd</code></strong></span> data
        files contain both table and
        <span class="bold"><strong>index</strong></span> data.
      </p><p>
        <code class="literal">InnoDB</code> tables created in file-per-table
        tablespaces can use <span class="bold"><strong>DYNAMIC</strong></span> or
        <span class="bold"><strong>COMPRESSED</strong></span> row format. These
        row formats enable <code class="literal">InnoDB</code> features such as
        <span class="bold"><strong>compression</strong></span>, efficient storage
        of <span class="bold"><strong>off-page columns</strong></span>, and large
        index key prefixes. General tablespaces support all row formats.
      </p><p>
        The system tablespace supports tables that use
        <span class="bold"><strong>REDUNDANT</strong></span>,
        <span class="bold"><strong>COMPACT</strong></span>, and
        <span class="bold"><strong>DYNAMIC</strong></span> row formats. System
        tablespace support for the
        <span class="bold"><strong>DYNAMIC</strong></span> row format was added in
        MySQL 5.7.6.
      </p><p>
        The <span class="bold"><strong>rows</strong></span> of an
        <code class="literal">InnoDB</code> table are organized into an index
        structure known as the <span class="bold"><strong>clustered
        index</strong></span>, with entries sorted based on the
        <span class="bold"><strong>primary key</strong></span> columns of the
        table. Data access is optimized for queries that filter and sort
        on the primary key columns, and each index contains a copy of
        the associated primary key columns for each entry. Modifying
        values for any of the primary key columns is an expensive
        operation. Thus an important aspect of <code class="literal">InnoDB</code>
        table design is choosing a primary key with columns that are
        used in the most important queries, and keeping the primary key
        short, with rarely changing values.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_backup">backup</a>, <a class="glossseealso" href="glossary.html#glos_clustered_index">clustered index</a>, <a class="glossseealso" href="glossary.html#glos_compact_row_format">compact row format</a>, <a class="glossseealso" href="glossary.html#glos_compressed_row_format">compressed row format</a>, <a class="glossseealso" href="glossary.html#glos_compression">compression</a>, <a class="glossseealso" href="glossary.html#glos_dynamic_row_format">dynamic row format</a>, <a class="glossseealso" href="glossary.html#glos_fast_index_creation">Fast Index Creation</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_off_page_column">off-page column</a>, <a class="glossseealso" href="glossary.html#glos_primary_key">primary key</a>, <a class="glossseealso" href="glossary.html#glos_redundant_row_format">redundant row format</a>, <a class="glossseealso" href="glossary.html#glos_row">row</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>.</p></dd><dt><a name="glos_table_lock"></a><span class="glossterm">table lock</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394317328"></a>
        A lock that prevents any other
        <span class="bold"><strong>transaction</strong></span> from accessing a
        table. <code class="literal">InnoDB</code> makes considerable effort to
        make such locks unnecessary, by using techniques such as
        <span class="bold"><strong>online DDL</strong></span>,
        <span class="bold"><strong>row locks</strong></span> and
        <span class="bold"><strong>consistent reads</strong></span> for processing
        <span class="bold"><strong>DML</strong></span> statements and
        <span class="bold"><strong>queries</strong></span>. You can create such a
        lock through SQL using the <code class="literal">LOCK TABLE</code>
        statement; one of the steps in migrating from other database
        systems or MySQL storage engines is to remove such statements
        wherever practical.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_consistent_read">consistent read</a>, <a class="glossseealso" href="glossary.html#glos_dml">DML</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_locking">locking</a>, <a class="glossseealso" href="glossary.html#glos_online_ddl">online DDL</a>, <a class="glossseealso" href="glossary.html#glos_query">query</a>, <a class="glossseealso" href="glossary.html#glos_row_lock">row lock</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_table_scan"></a><span class="glossterm">table scan</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_full_table_scan">full table scan</a>.</p></dd><dt><a name="glos_table_statistics"></a><span class="glossterm">table statistics</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_statistics">statistics</a>.</p></dd><dt><a name="glos_table_type"></a><span class="glossterm">table type</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394301792"></a>
        Obsolete synonym for <span class="bold"><strong>storage
        engine</strong></span>. We refer to
        <a class="link" href="innodb-storage-engine.html" title="Chapter 15 The InnoDB Storage Engine"><code class="literal">InnoDB</code></a> tables,
        <a class="link" href="storage-engines.html#myisam-storage-engine" title="16.2 The MyISAM Storage Engine"><code class="literal">MyISAM</code></a> tables, and so on.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_innodb">InnoDB</a>, <a class="glossseealso" href="glossary.html#glos_storage_engine">storage engine</a>.</p></dd><dt><a name="glos_tablespace"></a><span class="glossterm">tablespace</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394295536"></a>
        A data file that can hold data for one or more
        <code class="literal">InnoDB</code>
        <span class="bold"><strong>tables</strong></span> and associated
        <span class="bold"><strong>indexes</strong></span>.
      </p><p>
        The <span class="bold"><strong>system tablespace</strong></span> contains
        the <code class="literal">InnoDB</code> <span class="bold"><strong>data
        dictionary</strong></span>, and prior to MySQL 5.6 holds all other
        <code class="literal">InnoDB</code> tables by default.
      </p><p>
        The <a class="link" href="innodb-storage-engine.html#sysvar_innodb_file_per_table"><code class="literal">innodb_file_per_table</code></a>
        option, enabled by default in MySQL 5.6 and higher, allows
        tables to be created in their own tablespaces. File-per-table
        tablespaces support features such as efficient storage of
        <span class="bold"><strong>off-page columns</strong></span>, table
        compression, and transportable tablespaces. See
        <a class="xref" href="innodb-storage-engine.html#innodb-multiple-tablespaces" title="15.7.4 InnoDB File-Per-Table Tablespaces">Section 15.7.4, “InnoDB File-Per-Table Tablespaces”</a> for details.
      </p><p>
        <code class="literal">InnoDB</code> introduced general tablespaces in
        MySQL 5.7.6. General tablespaces are shared tablespaces created
        using <a class="link" href="sql-syntax.html#create-tablespace" title="13.1.19 CREATE TABLESPACE Syntax"><code class="literal">CREATE TABLESPACE</code></a> syntax.
        They can be created outside of the MySQL data directory, are
        capable of holding multiple tables, and support tables of all
        row formats.
      </p><p>
        MySQL NDB Cluster also groups its tables into tablespaces. See
        <a class="ulink" href="http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-disk-data-objects.html" target="_top">NDB Cluster Disk Data Objects</a> for details.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_compressed_row_format">compressed row format</a>, <a class="glossseealso" href="glossary.html#glos_data_dictionary">data dictionary</a>, <a class="glossseealso" href="glossary.html#glos_data_files">data files</a>, <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_general_tablespace">general tablespace</a>, <a class="glossseealso" href="glossary.html#glos_index">index</a>, <a class="glossseealso" href="glossary.html#glos_innodb_file_per_table">innodb_file_per_table</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_temporary_table"></a><span class="glossterm">temporary table</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394276032"></a>
        A <span class="bold"><strong>table</strong></span> whose data does not
        need to be truly permanent. For example, temporary tables might
        be used as storage areas for intermediate results in complicated
        calculations or transformations; this intermediate data would
        not need to be recovered after a crash. Database products can
        take various shortcuts to improve the performance of operations
        on temporary tables, by being less scrupulous about writing data
        to disk and other measures to protect the data across restarts.
      </p><p>
        Sometimes, the data itself is removed automatically at a set
        time, such as when the transaction ends or when the session
        ends. With some database products, the table itself is removed
        automatically too.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_table">table</a>.</p></dd><dt><a name="glos_temporary_tablespace"></a><span class="glossterm">temporary tablespace</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394271488"></a>
        The tablespace for non-compressed <code class="literal">InnoDB</code>
        <span class="bold"><strong>temporary tables</strong></span> and related
        objects, introduced in MySQL 5.7. The
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_temp_data_file_path"><code class="literal">innodb_temp_data_file_path</code></a>
        configuration file option defines the relative path, name, size,
        and attributes for temporary tablespace data files. If
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_temp_data_file_path"><code class="literal">innodb_temp_data_file_path</code></a> is
        not specified, the default behavior is to create a single
        auto-extending 12MB data file named <code class="filename">ibtmp1</code>
        in the data directory. The temporary tablespace is recreated on
        each server start and receives a dynamically generated
        <span class="bold"><strong>space ID</strong></span>. The temporary
        tablespace cannot reside on a raw device. Startup is refused if
        the temporary tablespace cannot be created.
      </p><p>
        The temporary tablespace is removed on normal shutdown or on an
        aborted initialization. The temporary tablespace is not removed
        when a crash occurs. In this case, the database administrator
        may remove the temporary tablespace manually or restart the
        server with the same configuration, which removes and recreates
        the temporary tablespace.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ibtmp_file">ibtmp file</a>, <a class="glossseealso" href="glossary.html#glos_space_id">space ID</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_temporary_table">temporary table</a>.</p></dd><dt><a name="glos_text_collection"></a><span class="glossterm">text collection</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394260464"></a>
        The set of columns included in a <span class="bold"><strong>FULLTEXT
        index</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_fulltext_index">FULLTEXT index</a>.</p></dd><dt><a name="glos_thread"></a><span class="glossterm">thread</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394257184"></a>
        A unit of processing that is typically more lightweight than a
        <span class="bold"><strong>process</strong></span>, allowing for greater
        <span class="bold"><strong>concurrency</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_master_thread">master thread</a>, <a class="glossseealso" href="glossary.html#glos_process">process</a>, <a class="glossseealso" href="glossary.html#glos_pthreads">Pthreads</a>.</p></dd><dt><a name="glos_torn_page"></a><span class="glossterm">torn page</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394251408"></a>
        An error condition that can occur due to a combination of I/O
        device configuration and hardware failure. If data is written
        out in chunks smaller than the <code class="literal">InnoDB</code>
        <span class="bold"><strong>page size</strong></span> (by default, 16KB), a
        hardware failure while writing could result in only part of a
        page being stored to disk. The <code class="literal">InnoDB</code>
        <span class="bold"><strong>doublewrite buffer</strong></span> guards
        against this possibility.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_doublewrite_buffer">doublewrite buffer</a>.</p></dd><dt><a name="glos_tps"></a><span class="glossterm">TPS</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394245664"></a>
        Acronym for <span class="quote">“<span class="quote"><span class="bold"><strong>transactions</strong></span>
        per second</span>”</span>, a unit of measurement sometimes used in
        benchmarks. Its value depends on the
        <span class="bold"><strong>workload</strong></span> represented by a
        particular benchmark test, combined with factors that you
        control such as the hardware capacity and database
        configuration.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>, <a class="glossseealso" href="glossary.html#glos_workload">workload</a>.</p></dd><dt><a name="glos_transaction"></a><span class="glossterm">transaction</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394240720"></a>
        Transactions are atomic units of work that can be
        <span class="bold"><strong>committed</strong></span> or
        <span class="bold"><strong>rolled back</strong></span>. When a transaction
        makes multiple changes to the database, either all the changes
        succeed when the transaction is committed, or all the changes
        are undone when the transaction is rolled back.
      </p><p>
        Database transactions, as implemented by
        <code class="literal">InnoDB</code>, have properties that are collectively
        known by the acronym <span class="bold"><strong>ACID</strong></span>, for
        atomicity, consistency, isolation, and durability.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_isolation_level">isolation level</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>.</p></dd><dt><a name="glos_transaction_id"></a><span class="glossterm">transaction ID</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394232448"></a>
        An internal field associated with each
        <span class="bold"><strong>row</strong></span>. This field is physically
        changed by <a class="link" href="sql-syntax.html#insert" title="13.2.6 INSERT Syntax"><code class="literal">INSERT</code></a>,
        <a class="link" href="sql-syntax.html#update" title="13.2.12 UPDATE Syntax"><code class="literal">UPDATE</code></a>, and
        <a class="link" href="sql-syntax.html#delete" title="13.2.2 DELETE Syntax"><code class="literal">DELETE</code></a> operations to record which
        <span class="bold"><strong>transaction</strong></span> has locked the row.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_implicit_row_lock">implicit row lock</a>, <a class="glossseealso" href="glossary.html#glos_row">row</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_transparent_page_compression"></a><span class="glossterm">transparent page compression</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394223472"></a>
        A feature added in MySQL 5.7.8 that permits page-level
        compression for <code class="literal">InnoDB</code> tables that reside in
        <span class="bold"><strong>file-per-table</strong></span> tablespaces.
        Page compression is enabled by specifying the
        <code class="literal">COMPRESSION</code> attribute with
        <a class="link" href="sql-syntax.html#create-table" title="13.1.18 CREATE TABLE Syntax"><code class="literal">CREATE TABLE</code></a> or
        <a class="link" href="sql-syntax.html#alter-table" title="13.1.8 ALTER TABLE Syntax"><code class="literal">ALTER TABLE</code></a>. For more
        information, see <a class="xref" href="innodb-storage-engine.html#innodb-page-compression" title="15.9.2 InnoDB Page Compression">Section 15.9.2, “InnoDB Page Compression”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_file_per_table">file-per-table</a>, <a class="glossseealso" href="glossary.html#glos_hole_punching">hole punching</a>, <a class="glossseealso" href="glossary.html#glos_sparse_file">sparse file</a>.</p></dd><dt><a name="glos_transportable_tablespace"></a><span class="glossterm">transportable tablespace</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394214304"></a>
        A feature that allows a
        <span class="bold"><strong>tablespace</strong></span> to be moved from one
        instance to another. Traditionally, this has not been possible
        for <code class="literal">InnoDB</code> tablespaces because all table data
        was part of the <span class="bold"><strong>system
        tablespace</strong></span>. In MySQL 5.6 and higher, the
        <a class="link" href="sql-syntax.html#flush-tables-for-export-with-list"><code class="literal">FLUSH
        TABLES ... FOR EXPORT</code></a> syntax prepares an
        <code class="literal">InnoDB</code> table for copying to another server;
        running <a class="link" href="sql-syntax.html#alter-table" title="13.1.8 ALTER TABLE Syntax"><code class="literal">ALTER TABLE
        ... DISCARD TABLESPACE</code></a> and
        <a class="link" href="sql-syntax.html#alter-table" title="13.1.8 ALTER TABLE Syntax"><code class="literal">ALTER TABLE ...
        IMPORT TABLESPACE</code></a> on the other server brings the
        copied data file into the other instance. A separate
        <span class="bold"><strong>.cfg file</strong></span>, copied along with
        the <span class="bold"><strong>.ibd file</strong></span>, is used to
        update the table metadata (for example the
        <span class="bold"><strong>space ID</strong></span>) as the tablespace is
        imported. See <a class="xref" href="innodb-storage-engine.html#tablespace-copying" title="15.7.6 Copying File-Per-Table Tablespaces to Another Instance">Section 15.7.6, “Copying File-Per-Table Tablespaces to Another Instance”</a> for usage
        information.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_cfg_file">.cfg file</a>, <a class="glossseealso" href="glossary.html#glos_ibd_file">.ibd file</a>, <a class="glossseealso" href="glossary.html#glos_space_id">space ID</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_tablespace">tablespace</a>.</p></dd><dt><a name="glos_troubleshooting"></a><span class="glossterm">troubleshooting</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394199648"></a>
        The process of determining the source of a problem. Some of the
        resources for troubleshooting MySQL problems include:
</p>
<div class="itemizedlist">
<ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
            <a class="xref" href="installing.html#starting-server-troubleshooting" title="2.10.2.1 Troubleshooting Problems Starting the MySQL Server">Section 2.10.2.1, “Troubleshooting Problems Starting the MySQL Server”</a>
          </p></li><li class="listitem"><p>
            <a class="xref" href="security.html#problems-connecting" title="6.2.9 Troubleshooting Problems Connecting to MySQL">Section 6.2.9, “Troubleshooting Problems Connecting to MySQL”</a>
          </p></li><li class="listitem"><p>
            <a class="xref" href="error-handling.html#resetting-permissions" title="B.5.3.2 How to Reset the Root Password">Section B.5.3.2, “How to Reset the Root Password”</a>
          </p></li><li class="listitem"><p>
            <a class="xref" href="error-handling.html#common-errors" title="B.5.2 Common Errors When Using MySQL Programs">Section B.5.2, “Common Errors When Using MySQL Programs”</a>
          </p></li><li class="listitem"><p>
            <a class="xref" href="innodb-storage-engine.html#innodb-troubleshooting" title="15.20 InnoDB Troubleshooting">Section 15.20, “InnoDB Troubleshooting”</a>.
</p></li></ul>
</div>
</dd><dt><a name="glos_truncate"></a><span class="glossterm">truncate</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394189952"></a>
        A <span class="bold"><strong>DDL</strong></span> operation that removes
        the entire contents of a table, while leaving the table and
        related indexes intact. Contrast with
        <span class="bold"><strong>drop</strong></span>. Although conceptually it
        has the same result as a <code class="literal">DELETE</code> statement
        with no <code class="literal">WHERE</code> clause, it operates differently
        behind the scenes: <code class="literal">InnoDB</code> creates a new empty
        table, drops the old table, then renames the new table to take
        the place of the old one. Because this is a DDL operation, it
        cannot be <span class="bold"><strong>rolled back</strong></span>.
      </p><p>
        If the table being truncated contains
        <span class="bold"><strong>foreign keys</strong></span> that reference
        another table, the truncation operation uses a slower method of
        operation, deleting one row at a time so that corresponding rows
        in the referenced table can be deleted as needed by any
        <code class="literal">ON DELETE CASCADE</code> clause. (MySQL 5.5 and
        higher do not allow this slower form of truncate, and return an
        error instead if foreign keys are involved. In this case, use a
        <code class="literal">DELETE</code> statement instead.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_ddl">DDL</a>, <a class="glossseealso" href="glossary.html#glos_drop">drop</a>, <a class="glossseealso" href="glossary.html#glos_foreign_key">foreign key</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>.</p></dd><dt><a name="glos_tuple"></a><span class="glossterm">tuple</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394178144"></a>
        A technical term designating an ordered set of elements. It is
        an abstract notion, used in formal discussions of database
        theory. In the database field, tuples are usually represented by
        the columns of a table row. They could also be represented by
        the result sets of queries, for example, queries that retrieved
        only some columns of a table, or columns from joined tables.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_cursor">cursor</a>.</p></dd><dt><a name="glos_two_phase_commit"></a><span class="glossterm">two-phase commit</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394175152"></a>
        An operation that is part of a distributed
        <span class="bold"><strong>transaction</strong></span>, under the
        <span class="bold"><strong>XA</strong></span> specification. (Sometimes
        abbreviated as 2PC.) When multiple databases participate in the
        transaction, either all databases
        <span class="bold"><strong>commit</strong></span> the changes, or all
        databases <span class="bold"><strong>roll back</strong></span> the
        changes.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>, <a class="glossseealso" href="glossary.html#glos_xa">XA</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">U</h3>
<dl><dt><a name="glos_undo"></a><span class="glossterm">undo</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394167456"></a>
        Data that is maintained throughout the life of a
        <span class="bold"><strong>transaction</strong></span>, recording all
        changes so that they can be undone in case of a
        <span class="bold"><strong>rollback</strong></span> operation. It is
        stored in the <span class="bold"><strong>undo log</strong></span> either
        within the <span class="bold"><strong>system tablespace</strong></span> or
        in separate <span class="bold"><strong>undo tablespaces</strong></span>.
        As of MySQL 8.0, undo logs reside in undo tablespaces by
        default.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_rollback_segment">rollback segment</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>, <a class="glossseealso" href="glossary.html#glos_undo_tablespace">undo tablespace</a>.</p></dd><dt><a name="glos_undo_buffer"></a><span class="glossterm">undo buffer</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_undo_log">undo log</a>.</p></dd><dt><a name="glos_undo_log"></a><span class="glossterm">undo log</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394157104"></a>
        A storage area that holds copies of data modified by active
        <span class="bold"><strong>transactions</strong></span>. If another
        transaction needs to see the original data (as part of a
        <span class="bold"><strong>consistent read</strong></span> operation), the
        unmodified data is retrieved from this storage area.
      </p><p>
        In MySQL 5.6 and higher, you can use the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_undo_tablespaces"><code class="literal">innodb_undo_tablespaces</code></a> to
        create undo logs in <span class="bold"><strong>undo
        tablespaces</strong></span>, optionally stored on another storage
        device such as an <span class="bold"><strong>SSD</strong></span>. In MySQL
        8.0, undo logs reside in undo tablespaces by default.
      </p><p>
        The undo log is split into separate portions, the
        <span class="bold"><strong>insert undo buffer</strong></span> and the
        <span class="bold"><strong>update undo buffer</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_consistent_read">consistent read</a>, <a class="glossseealso" href="glossary.html#glos_rollback_segment">rollback segment</a>, <a class="glossseealso" href="glossary.html#glos_ssd">SSD</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>, <a class="glossseealso" href="glossary.html#glos_undo_tablespace">undo tablespace</a>.</p></dd><dt><a name="glos_undo_log_segment"></a><span class="glossterm">undo log segment</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394145136"></a>
        A collection of <span class="bold"><strong>undo logs</strong></span>. Undo
        log segments exists within <span class="bold"><strong>rollback
        segments</strong></span>. An undo log segment might contain undo logs
        from multiple transactions. An undo log segment can only be used
        by one transaction at a time but can be reused after it is
        released at transaction <span class="bold"><strong>commit</strong></span>
        or <span class="bold"><strong>rollback</strong></span>. May also be
        referred to as an <span class="quote">“<span class="quote">undo segment</span>”</span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_rollback">rollback</a>, <a class="glossseealso" href="glossary.html#glos_rollback_segment">rollback segment</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>.</p></dd><dt><a name="glos_undo_tablespace"></a><span class="glossterm">undo tablespace</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394137440"></a>
        An undo tablespace contains <span class="bold"><strong>undo
        logs</strong></span>. Undo logs exist within
        <span class="bold"><strong>undo log segments</strong></span>, which are
        contained within <span class="bold"><strong>rollback
        segments</strong></span>. Rollback segments have traditionally
        resided in the system tablespace. As of MySQL 5.6, rollback
        segments can reside in undo tablespaces. The number of undo
        tablespaces is controlled by the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_undo_tablespaces"><code class="literal">innodb_undo_tablespaces</code></a>
        configuration option.
      </p><p>
        For more information, see
        <a class="xref" href="innodb-storage-engine.html#innodb-undo-tablespace" title="15.7.8 Configuring Undo Tablespaces">Section 15.7.8, “Configuring Undo Tablespaces”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_rollback_segment">rollback segment</a>, <a class="glossseealso" href="glossary.html#glos_system_tablespace">system tablespace</a>, <a class="glossseealso" href="glossary.html#glos_undo_log">undo log</a>, <a class="glossseealso" href="glossary.html#glos_undo_log_segment">undo log segment</a>.</p></dd><dt><a name="glos_unique_constraint"></a><span class="glossterm">unique constraint</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394128544"></a>
        A kind of <span class="bold"><strong>constraint</strong></span> that
        asserts that a column cannot contain any duplicate values. In
        terms of <span class="bold"><strong>relational</strong></span> algebra, it
        is used to specify 1-to-1 relationships. For efficiency in
        checking whether a value can be inserted (that is, the value
        does not already exist in the column), a unique constraint is
        supported by an underlying <span class="bold"><strong>unique
        index</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_constraint">constraint</a>, <a class="glossseealso" href="glossary.html#glos_relational">relational</a>, <a class="glossseealso" href="glossary.html#glos_unique_index">unique index</a>.</p></dd><dt><a name="glos_unique_index"></a><span class="glossterm">unique index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394122512"></a>
        An index on a column or set of columns that have a
        <span class="bold"><strong>unique constraint</strong></span>. Because the
        index is known not to contain any duplicate values, certain
        kinds of lookups and count operations are more efficient than in
        the normal kind of index. Most of the lookups against this type
        of index are simply to determine if a certain value exists or
        not. The number of values in the index is the same as the number
        of rows in the table, or at least the number of rows with
        non-null values for the associated columns.
      </p><p>
        <span class="bold"><strong>Change buffering</strong></span> optimization
        does not apply to unique indexes. As a workaround, you can
        temporarily set <code class="literal">unique_checks=0</code> while doing a
        bulk data load into an <code class="literal">InnoDB</code> table.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_cardinality">cardinality</a>, <a class="glossseealso" href="glossary.html#glos_change_buffering">change buffering</a>, <a class="glossseealso" href="glossary.html#glos_unique_constraint">unique constraint</a>, <a class="glossseealso" href="glossary.html#glos_unique_key">unique key</a>.</p></dd><dt><a name="glos_unique_key"></a><span class="glossterm">unique key</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394114352"></a>
        The set of columns (one or more) comprising a
        <span class="bold"><strong>unique index</strong></span>. When you can
        define a <code class="literal">WHERE</code> condition that matches exactly
        one row, and the query can use an associated unique index, the
        lookup and error handling can be performed very efficiently.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_cardinality">cardinality</a>, <a class="glossseealso" href="glossary.html#glos_unique_constraint">unique constraint</a>, <a class="glossseealso" href="glossary.html#glos_unique_index">unique index</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">V</h3>
<dl><dt><a name="glos_variable_length_type"></a><span class="glossterm">variable-length type</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394108480"></a>
        A data type of variable length.
        <a class="link" href="data-types.html#char" title="11.4.1 The CHAR and VARCHAR Types"><code class="literal">VARCHAR</code></a>,
        <a class="link" href="data-types.html#binary-varbinary" title="11.4.2 The BINARY and VARBINARY Types"><code class="literal">VARBINARY</code></a>, and
        <a class="link" href="data-types.html#blob" title="11.4.3 The BLOB and TEXT Types"><code class="literal">BLOB</code></a> and
        <a class="link" href="data-types.html#blob" title="11.4.3 The BLOB and TEXT Types"><code class="literal">TEXT</code></a> types are variable-length
        types.
      </p><p>
        <code class="literal">InnoDB</code> treats fixed-length fields greater
        than or equal to 768 bytes in length as variable-length fields,
        which can be stored <span class="bold"><strong>off-page</strong></span>.
        For example, a <code class="literal">CHAR(255)</code> column can exceed
        768 bytes if the maximum byte length of the character set is
        greater than 3, as it is with <code class="literal">utf8mb4</code>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_off_page_column">off-page column</a>, <a class="glossseealso" href="glossary.html#glos_overflow_page">overflow page</a>.</p></dd><dt><a name="glos_victim"></a><span class="glossterm">victim</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394096912"></a>
        The <span class="bold"><strong>transaction</strong></span> that is
        automatically chosen to be <span class="bold"><strong>rolled
        back</strong></span> when a <span class="bold"><strong>deadlock</strong></span>
        is detected. <code class="literal">InnoDB</code> rolls back the
        transaction that has updated the fewest rows.
      </p><p>
        <span class="bold"><strong>Deadlock detection</strong></span> can be
        disabled using the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_deadlock_detect"><code class="literal">innodb_deadlock_detect</code></a>
        configuration option.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_deadlock">deadlock</a>, <a class="glossseealso" href="glossary.html#glos_deadlock_detection">deadlock detection</a>, <a class="glossseealso" href="glossary.html#glos_innodb_lock_wait_timeout">innodb_lock_wait_timeout</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>.</p></dd><dt><a name="glos_virtual_column"></a><span class="glossterm">virtual column</span></dt><dd><p>See <a class="glosssee" href="glossary.html#glos_virtual_generated_column">virtual generated column</a>.</p></dd><dt><a name="glos_virtual_generated_column"></a><span class="glossterm">virtual generated column</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394085872"></a>
        A column whose values are computed from an expression included
        in the column definition. Column values are not stored, but are
        evaluated when rows are read, immediately after any
        <code class="literal">BEFORE</code> triggers. A virtual generated column
        takes no storage. <code class="literal">InnoDB</code> supports secondary
        indexes on virtual generated columns.
      </p><p>
        Contrast with <span class="bold"><strong>stored generated
        column</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_base_column">base column</a>, <a class="glossseealso" href="glossary.html#glos_generated_column">generated column</a>, <a class="glossseealso" href="glossary.html#glos_stored_generated_column">stored generated column</a>.</p></dd><dt><a name="glos_virtual_index"></a><span class="glossterm">virtual index</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394079328"></a>
        A virtual index is a <span class="bold"><strong>secondary
        index</strong></span> on one or more <span class="bold"><strong> virtual
        generated columns</strong></span> or on a combination of virtual
        generated columns and regular columns or stored generated
        columns. For more information, see
        <a class="xref" href="sql-syntax.html#create-table-secondary-indexes" title="13.1.18.9 Secondary Indexes and Generated Columns">Section 13.1.18.9, “Secondary Indexes and Generated Columns”</a>.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_secondary_index">secondary index</a>, <a class="glossseealso" href="glossary.html#glos_stored_generated_column">stored generated column</a>, <a class="glossseealso" href="glossary.html#glos_virtual_generated_column">virtual generated column</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">W</h3>
<dl><dt><a name="glos_wait"></a><span class="glossterm">wait</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394072784"></a>
        When an operation, such as acquiring a
        <span class="bold"><strong>lock</strong></span>,
        <span class="bold"><strong>mutex</strong></span>, or
        <span class="bold"><strong>latch</strong></span>, cannot be completed
        immediately, <code class="literal">InnoDB</code> pauses and tries again.
        The mechanism for pausing is elaborate enough that this
        operation has its own name, the
        <span class="bold"><strong>wait</strong></span>. Individual threads are
        paused using a combination of internal <code class="literal">InnoDB</code>
        scheduling, operating system <code class="literal">wait()</code> calls,
        and short-duration <span class="bold"><strong>spin</strong></span> loops.
      </p><p>
        On systems with heavy load and many transactions, you might use
        the output from the <code class="literal">SHOW INNODB STATUS</code>
        command or <span class="bold"><strong>Performance Schema</strong></span>
        to determine whether threads are spending too much time waiting,
        and if so, how you can improve
        <span class="bold"><strong>concurrency</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_concurrency">concurrency</a>, <a class="glossseealso" href="glossary.html#glos_latch">latch</a>, <a class="glossseealso" href="glossary.html#glos_lock">lock</a>, <a class="glossseealso" href="glossary.html#glos_mutex">mutex</a>, <a class="glossseealso" href="glossary.html#glos_performance_schema">Performance Schema</a>, <a class="glossseealso" href="glossary.html#glos_spin">spin</a>.</p></dd><dt><a name="glos_warm_backup"></a><span class="glossterm">warm backup</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394058848"></a>
        A <span class="bold"><strong>backup</strong></span> taken while the
        database is running, but that restricts some database operations
        during the backup process. For example, tables might become
        read-only. For busy applications and websites, you might prefer
        a <span class="bold"><strong>hot backup</strong></span>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_backup">backup</a>, <a class="glossseealso" href="glossary.html#glos_cold_backup">cold backup</a>, <a class="glossseealso" href="glossary.html#glos_hot_backup">hot backup</a>.</p></dd><dt><a name="glos_warm_up"></a><span class="glossterm">warm up</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394053568"></a>
        To run a system under a typical
        <span class="bold"><strong>workload</strong></span> for some time after
        startup, so that the <span class="bold"><strong>buffer
        pool</strong></span> and other memory regions are filled as they
        would be under normal conditions. This process happens naturally
        over time when a MySQL server is restarted or subjected to a new
        workload.
      </p><p>
        Typically, you run a workload for some time to warm up the
        buffer pool before running performance tests, to ensure
        consistent results across multiple runs; otherwise, performance
        might be artificially low during the first run.
      </p><p>
        In MySQL 5.6, you can speed up the warmup process by enabling
        the
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_buffer_pool_dump_at_shutdown"><code class="literal">innodb_buffer_pool_dump_at_shutdown</code></a>
        and
        <a class="link" href="innodb-storage-engine.html#sysvar_innodb_buffer_pool_load_at_startup"><code class="literal">innodb_buffer_pool_load_at_startup</code></a>
        configuration options, to bring the contents of the buffer pool
        back into memory after a restart. These options are enabled by
        default in MySQL 5.7. See
        <a class="xref" href="innodb-storage-engine.html#innodb-preload-buffer-pool" title="15.6.3.8 Saving and Restoring the Buffer Pool State">Section 15.6.3.8, “Saving and Restoring the Buffer Pool State”</a>.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_workload">workload</a>.</p></dd><dt><a name="glos_workload"></a><span class="glossterm">workload</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394044160"></a>
        The combination and volume of
        <span class="bold"><strong>SQL</strong></span> and other database
        operations, performed by a database application during typical
        or peak usage. You can subject the database to a particular
        workload during performance testing to identify
        <span class="bold"><strong>bottlenecks</strong></span>, or during capacity
        planning.
      </p><p>See Also <a class="glossseealso" href="glossary.html#glos_bottleneck">bottleneck</a>, <a class="glossseealso" href="glossary.html#glos_cpu_bound">CPU-bound</a>, <a class="glossseealso" href="glossary.html#glos_disk_bound">disk-bound</a>, <a class="glossseealso" href="glossary.html#glos_sql">SQL</a>.</p></dd><dt><a name="glos_write_combining"></a><span class="glossterm">write combining</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394038304"></a>
        An optimization technique that reduces write operations when
        <span class="bold"><strong>dirty pages</strong></span> are
        <span class="bold"><strong>flushed</strong></span> from the
        <code class="literal">InnoDB</code> <span class="bold"><strong>buffer
        pool</strong></span>. If a row in a page is updated multiple times,
        or multiple rows on the same page are updated, all of those
        changes are stored to the data files in a single write operation
        rather than one write for each change.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_dirty_page">dirty page</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">X</h3>
<dl><dt><a name="glos_xa"></a><span class="glossterm">XA</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394031104"></a>
        A standard interface for coordinating distributed
        <span class="bold"><strong>transactions</strong></span>, allowing multiple
        databases to participate in a transaction while maintaining
        <span class="bold"><strong>ACID</strong></span> compliance. For full
        details, see <a class="xref" href="sql-syntax.html#xa" title="13.3.8 XA Transactions">Section 13.3.8, “XA Transactions”</a>.
      </p><p>
        XA Distributed Transaction support is enabled by default. If you
        are not using this feature, you can disable the
        <a class="ulink" href="http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_support_xa" target="_top"><code class="literal">innodb_support_xa</code></a> configuration
        option, avoiding the performance overhead of an extra fsync for
        each transaction.
      </p><p>
        As of MySQL 5.7.10, disabling
        <a class="ulink" href="http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_support_xa" target="_top"><code class="literal">innodb_support_xa</code></a> is not
        permitted as it makes replication unsafe and prevents
        performance gains associated with <span class="bold"><strong>binary
        log</strong></span> group commit. The
        <a class="ulink" href="http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_support_xa" target="_top"><code class="literal">innodb_support_xa</code></a> configuration
        option is removed in MySQL 8.0.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_acid">ACID</a>, <a class="glossseealso" href="glossary.html#glos_binary_log">binary log</a>, <a class="glossseealso" href="glossary.html#glos_commit">commit</a>, <a class="glossseealso" href="glossary.html#glos_transaction">transaction</a>, <a class="glossseealso" href="glossary.html#glos_two_phase_commit">two-phase commit</a>.</p></dd></dl>
</div>
<div class="glossdiv">
<h3 class="title">Y</h3>
<dl><dt><a name="glos_young"></a><span class="glossterm">young</span></dt><dd class="glossdef"><p>
<a class="indexterm" name="idm139899394018208"></a>
        A characteristic of a <span class="bold"><strong>page</strong></span> in
        the <code class="literal">InnoDB</code> <span class="bold"><strong>buffer
        pool</strong></span> meaning it has been accessed recently, and so is
        moved within the buffer pool data structure, so that it will not
        be <span class="bold"><strong>flushed</strong></span> soon by the
        <span class="bold"><strong>LRU</strong></span> algorithm. This term is
        used in some <span class="bold"><strong>INFORMATION_SCHEMA</strong></span>
        column names of tables related to the buffer pool.
</p><p>See Also <a class="glossseealso" href="glossary.html#glos_buffer_pool">buffer pool</a>, <a class="glossseealso" href="glossary.html#glos_flush">flush</a>, <a class="glossseealso" href="glossary.html#glos_information_schema">INFORMATION_SCHEMA</a>, <a class="glossseealso" href="glossary.html#glos_lru">LRU</a>, <a class="glossseealso" href="glossary.html#glos_page">page</a>.</p></dd></dl>
</div>

</div>

</div>
<div class="copyright-footer">

</div>
</body>
</html>
<div class="copyright-footer">

</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="dynindex-isolevel.html">Prev</a></td>
<td width="20%" align="center"><a accesskey="u" href="">Up</a></td>
<td width="40%" align="right"> </td>
</tr>
<tr>
<td width="40%" align="left" valign="top"> Transaction Isolation Level Index</td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td>
<td width="40%" align="right" valign="top"></td>
</tr>
</table>
</div>
</body>
</html>
